Final Review: M-43: chrome.vpnProvider API

[Saswat Panigrahi]

Dear All

Over the past 4 months we have worked extensively with external developers (top 5 VPN providers) who have been using this API. Now for version 43 we are requesting a final review. 

This Chrome OS only and mostly targeted for Enterprises. Must enterprise deals of Chromebooks are blocked since the top 5 VPN providers in Enterprise are not supported on Chrome OS. This addresses that. Launch bug & public API documentation here.

A brief recap of timeline:

• Sep 2014: Discussed needs with key VPN providers
• Oct 2014: App proposal circulated to apps-dev@ & security-enamel@ & master tracking sheet updated
• Nov 2014: Launch bug filed
• Dec 2014: 41 Dev has first version of API that Pulse Secure and other developers begin using & giving feedback.
• Jan 2015: Security Survey filled
• Feb 2015: More developer feedback, tests & fixes.
• Mar 2015: Seeking approval for final launch. Mutliple VPN vendors ready to launch in M43 Stable time frame.

Many thanks

Saswat

---------- Forwarded message ---------
From: Benjamin Kalman <kal...@chromium.org>
Date: Thu, Oct 16, 2014 at 7:18 PM
Subject: Re: API Proposal
To: Prabhu Kaliamoorthi <kaliam...@chromium.org>, Mustafa Emre Acer <mea...@chromium.org>
Cc: apps-dev <apps...@chromium.org>, security-enamel <securit...@chromium.org>, Drew Wilson <atwi...@chromium.org>, Mattias Nissler <mnis...@chromium.org>, Bartosz Fabianowski <bar...@chromium.org>, Philipp Neubeck <pneu...@chromium.org>

API lgtm (with nits), you'll want meacer's sign off as well.

On Tue, Oct 14, 2014 at 5:43 AM, Prabhu Kaliamoorthi <kaliam...@chromium.org> wrote:

We are working on a design to support VPN clients built by third party on Chrome OS. 

We want to add new extension APIs for this. 

Here is a proposal on the new extension API.

If you want to know more details, we could setup a meeting and share relevant documents directly with the reviewers.

Cheers,

Prabhu.

[Benjamin Kalman]

How has this changed since the initial proposal?

[Saswat Panigrahi]

• The fields in the dictionary Parameters has changed to support split tunnel VPN function.
  
• The original proposal used a integer handle to identify configurations. It is changed to string identifiers to support GUIDs in the future.
  
• New signals are added to support UI and allow the future addition of policy support for VPN clients.
  
• The enum VpnConnectionState is trimmed down to the needed states alone.
  

Full Diff in the IDL since the beginning

(resending from correct address)

On Tue, Mar 17, 2015 at 6:52 PM, Saswat Panigrahi <sas...@google.com> wrote:

• The fields in the dictionary Parameters has changed to support split tunnel VPN function.
  
• The original proposal used a integer handle to identify configurations. It is changed to string identifiers to support GUIDs in the future.
  
• New signals are added to support UI and allow the future addition of policy support for VPN clients.
  
• The enum VpnConnectionState is trimmed down to the needed states alone.
  

Full Diff in the IDL since the beginning

Saswat Panigrahi | Product Manager - Chrome for Work | sas...@google.com | +49 89 839300999

Google Germany GmbH

Dienerstr. 12, 80331 Munich

Registergericht und -nummer: Hamburg, HRB 86891

Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores

[Benjamin Kalman]

I see diffs like:

-  // The enum is used by the platform to notify the client of
-  // connection and network related status.
-  // TODO: Document the messages
+  // The enum is used by the platform to notify the client of the VPN session
+  // status.
   enum PlatformMessage {
     connected,
     disconnected,
-    underlyingNetworkDisconnected,
     error
   };

Can these be documented now?

[Prabhu Kaliamoorthi]

Sending again from my chromium id.

I created CL https://codereview.chromium.org/1020433002/ for updating the documentation and switching the flag to stable.

On Wed, Mar 18, 2015 at 10:30 AM Prabhu Kaliamoorthi <kaliam...@google.com> wrote:

I created CL https://codereview.chromium.org/1020433002/ for updating the documentation and switching the flag to stable.

[Benjamin Kalman]

lgtm, any other comments?

you still need security signoff.

[Saswat Panigrahi]

Thanks Ben

Adrienne, Mustafa - you had LGTMed this at the proposal stage. Could you please take a look?

FYI - for chrome os security, jorgelo@ is familiar with this feature.

[Mustafa Emre Acer]

Looks like there aren't any changes as to how the user enables/disables the vpn provider, so LGTM. Please also wait for Adrienne's signoff.

[Adrienne Porter Felt]

one more time with @chromium.org

On Wed, Mar 18, 2015 at 12:52 PM, Adrienne Porter Felt <fe...@google.com> wrote:

There are a number of security-related comments on the design doc that were never resolved. Can you please update the design doc with any changes that were made, respond to the comments, and/or resolve the comments?

[Prabhu Kaliamoorthi]

I have updated the comments in the design document. Please take another look. 

[Adrienne Porter Felt]

On Fri, Mar 20, 2015 at 4:29 PM, Adrienne Porter Felt <fe...@google.com> wrote:

Thanks Prabhu. There are still some open questions in the doc at the bottom (quoted here), can you tell me what you ended up doing?

General Comments and Observations
The current VPN proposal expects the user to initiate the VPN connection via an appropriate UI. This ensures that evil VPN is not allowed to auto-install and redirect all the network traffic to it. Though this is relatively secure, the following usability related questions remain open.
Should the user initiate the connection every time or can he ask the platform to auto-connect in subsequent user logins?
Do we allow admins to force install a VPN extension and initiate the connection automatically?
Some URLs may need to be accessed with and without VPN, for example request to DM server should probably tried

[Prabhu Kaliamoorthi]

I have responded to the open questions in the document itself, please take a look.

[Adrienne Porter Felt]

As demanded by ritual, reposting from @chromium.org

On Tue, Mar 24, 2015 at 10:25 AM, Adrienne Porter Felt <fe...@google.com> wrote:

LGTM

By the way, could someone on your team take a look at https://code.google.com/p/chromium/issues/detail?id=369838? Right now, there is no notification when a VPN connection drops. A user might therefore continue accessing HTTP traffic over an insecure network, thinking they are protected by a VPN. I imagine that addressing this would be useful both for first-party VPN and third-party VPN. The bug has been stale since May 2014. 

[Prabhu Kaliamoorthi]

We have crbug.com/463090 open to track the problem for third party VPN. This is blocking the launch bug. We'll get to this before launch.

On Tue, Mar 24, 2015 at 6:25 PM Adrienne Porter Felt <fe...@google.com> wrote:

LGTM

By the way, could someone on your team take a look at https://code.google.com/p/chromium/issues/detail?id=369838? Right now, there is no notification when a VPN connection drops. A user might therefore continue accessing HTTP traffic over an insecure network, thinking they are protected by a VPN. I imagine that addressing this would be useful both for first-party VPN and third-party VPN. The bug has been stale since May 2014.