Adding CryptAuth and ProximityAuth Services

926 views
Skip to first unread message

Kyle Horimoto

unread,
Jun 23, 2017, 1:31:57 AM6/23/17
to servic...@chromium.org, te...@chromium.org
Hi services-dev,

Tim (cc'ed) and I would like two add two new related Chromium services.

Background: The Instant Tethering and EasyUnlock features in Chromium establish connections between multiple devices with the same Google account and exchange protocol messages via these connections. More projects are lined up to do similar inter-device communications, so this framework will be expanding to new clients.

(1) CryptAuth Service: This service is responsible for syncing device metadata (i.e., metadata corresponding to each device on a given account) with the CryptAuth back-end. It currently has an implementation in //components/cryptauth. The proposed API would provide getters for synced device data. Pseudocode:

struct RemoteDevice { string id, ... }

RemoteDevice[] GetSyncedDevices();

(2) ProximityAuth Service: This service establishes communication channels between devices on a given account and provides send/receive functionality. Currently, all channels are over BLE, but there are plans to extend this to create other mediums. It currently has some of its implementation in //components/cryptauth and some in //chromeos/components/tether. We would refactor these modules as part of the servicification. The proposed API would provide a mechanism to connect to remote devices and send/receive messages. Pseudocode:

enum ConnectionMode { BLE_CENTRAL, BLE_PERIPHERAL, ... }
enum ConnectionStatus { DISCONNECTED, CONNECTED, ... }

struct Message { string feature, string message_b64 }

interface Observer {
  OnConnectionStatusChanged(string device_id, ConnectionStatus status);
  OnMessageReceived(Message message);
}

void ConnectToDevice(RemoteDevice device, ConnectionMode mode);
void SendMessageToDevice(string device_id, Message message);
void AddObserver(Observer observer);

Proposal: Create two services. My plan is to implement these in //services. However, as I was reading the Servicification Strategies document, I saw that it is also possible to implement services within other directories (e.g., //components). Which is the right place for these services? If the services end up living in //services, should the implementation still live in //components?

I'm working on a complete design document and will pass it along when I am finished. For now, I want to get some feedback early before I finish the complete design.

Let me know if you have comments/questions/concerns!

Thanks,
Kyle Horimoto

Colin Blundell

unread,
Jun 23, 2017, 9:36:04 AM6/23/17
to Kyle Horimoto, servic...@chromium.org, te...@chromium.org
Hi Kyle,

Thanks for reaching out! Something that I can't grok out of the below message is what your motivations are for servicifying these features. Could you expand on that? That might also help us better understand where this code should end up. I do see below that you're looking to have new clients of these features, but presumably you could just add new clients of the existing code.

Best,

Colin

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

Ken Rockot

unread,
Jun 23, 2017, 10:46:46 AM6/23/17
to Colin Blundell, Kyle Horimoto, services-dev, te...@chromium.org
My first very high-level question here is whether or not there is really anything Chrome or Chrome OS specific about these interfaces. Clearly the implementations are quite tightly bound to Chrome and Chrome OS details; but the interfaces themselves seem like a reasonable fit for the identity service, assuming we'd want to expand the scope of that service to cover device identity as well as user identity. (I might be wrong about this, so Colin should probably weigh in too.)

At the very least I doubt we'd want these as separate services in //services.

Even if they're built outside of //services though, I haven't yet understood why these would be separated. They seem to provide loosely related functionality, and in general with service design we've tried to maintain an initial bias toward less granularity.

Colin


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

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

To post to this group, send email to servic...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAMGE5NHq7V7qMDDRcxTjOzWrmZ%3DPPQpffRrhsjxQMKyMf-5Vxg%40mail.gmail.com.

John Abd-El-Malek

unread,
Jun 23, 2017, 12:22:24 PM6/23/17
to Kyle Horimoto, services-dev, te...@chromium.org
Per https://chromium.googlesource.com/chromium/src/+/master/services#Overview , services/ is meant to be foundational services. These two services you mention seem like feature-specific which would preclude them from being foundational and therefore in src/services. However this is why we're thinking of having src/chrome/services which would contain chrome feature-specific services.

Does that make sense?


I'm working on a complete design document and will pass it along when I am finished. For now, I want to get some feedback early before I finish the complete design.

Let me know if you have comments/questions/concerns!

Thanks,
Kyle Horimoto

--

Kyle Horimoto

unread,
Jun 23, 2017, 1:41:20 PM6/23/17
to John Abd-El-Malek, services-dev, te...@chromium.org
Thanks for the responses!

@blundell: It has been my understanding that features which do not logically need to be part of the browser itself should live in separate services, but maybe I misinterpreted things. My motivations are:
  • Continuing to build these features into the browser itself will provide less future flexibility/extensibility and will bloat the browser as the dependencies become more entangled.
  • Ensuring that the code runs in isolation. With more clients being added (including from ARC++), it would provide a clean abstraction. Currently, our code is assumed to run on the main thread, and servicification would provide this as a guarantee.
Would you recommend I move forward with the servicification approach? Or does continuing to build the features into the browser make more sense?

@rockot/jam: Thanks - it looks like since this would not be a "foundational service," it does not belong in //services and would be better placed in a component. Regarding separation into two services: you're correct that these are loosely related, but we want to keep them decoupled for future extensibility. We may, for example, provide a different mechanism for syncing down remote device metadata or even allow a framework to allow non-Google entities to provide remote device metadata. Tightly coupling these two services eliminates the ability to swap out our remote device syncing for another implementation.

Tim Song

unread,
Jun 23, 2017, 2:40:04 PM6/23/17
to Kyle Horimoto, John Abd-El-Malek, services-dev
Hi everyone,

I want to give some more context about the motivation of our servicification. 

Our primary motivation is introducing a sane and ordered way to scale the various multi-device features for Chrome and ChromeOS. Currently we are developing these features:
  1. EasyUnlock
  2. Magic Tether
  3. Sms Sync
We also have good reason to believe that there will be more features in the future.

On Android (GMSCore), we have already implemented these CryptAuth and ProximityAuth service API that these higher level features then use. Having a concrete API and service level separation has worked out very well for us on Android, and we would like to do the same in Chrome.

At the moment, our code is coupled to chrome in a way that is quite hard to extract. Given that these multi-device features are not core functionality of the browser, it makes sense to turn them into services to make Chrome more modular and give us more flexibility. 

Regards,
Tim

Rahul Chaturvedi

unread,
Jun 23, 2017, 4:47:25 PM6/23/17
to Tim Song, Kyle Horimoto, John Abd-El-Malek, services-dev
These may seem specific to Chrome at the moment, but the services provided aren't bound to the "browser". EasyUnlock is required from the login/lock screens, which we are already decoupling from Chrome and one day hope to be able to run independent of the Browser. Magic Tether is again, currently bound to UI from within the browser, but there is no fundamental reason it should be.
However, this does not necessarily qualify this as separate "Foundation" services. I can however, see these as part of another larger foundation service.

It would be great to see a design doc for this with motivations, use cases and some alternative solutions to discuss the pros/cons of.

/rkc

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAGVBWjSf2CsSAXcTs93mNQL24Y_QaV_D%2BbxBb7Nvz0T_7Y4ivQ%40mail.gmail.com.

John Abd-El-Malek

unread,
Jun 23, 2017, 8:03:08 PM6/23/17
to Rahul Chaturvedi, Tim Song, Kyle Horimoto, services-dev
+1 to getting more background in a design doc.

Note that if this is something that's not tied to chrome, other options could be to put it in components/. I think as a team we have to figure out exactly what the boundary of what goes in src/services vs outside. It's still fuzzy and something we're still trying to nail down. One criteria could be whether something is generic and used by many callers. So having a list of users in the design doc, even future ones, would be helpful.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAJ2L3AZy8DmCc%2BJGt4X%3Dim6N2yhY%2B7Ng-ZPquJ2hh54OqoAyuw%40mail.gmail.com.

Colin Blundell

unread,
Jun 26, 2017, 10:06:03 AM6/26/17
to John Abd-El-Malek, Rahul Chaturvedi, Tim Song, Kyle Horimoto, services-dev
On Sat, Jun 24, 2017 at 2:03 AM John Abd-El-Malek <j...@chromium.org> wrote:
+1 to getting more background in a design doc.

Note that if this is something that's not tied to chrome, other options could be to put it in components/. I think as a team we have to figure out exactly what the boundary of what goes in src/services vs outside. It's still fuzzy and something we're still trying to nail down.

Slightly off-topic, but I strongly agree that we haven't yet hit on something that feels like the sweet spot here both in terms of boundary-setting and in terms of how to deal with things that have the requirements of services but that we don't think are //services. The more that I look at //components/printing/service, the less comfortable I am with the idea of having named services scattered around semi-randomly through the codebase. I've been brainstorming alternatives but haven't come up with anything that feels great yet (if the solution was obvious, we would have already hit it). I'm going to keep chewing this over in the back of my head, and I encourage others to as well.
 

/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

Kyle Horimoto

unread,
Jun 28, 2017, 8:37:58 PM6/28/17
to Colin Blundell, John Abd-El-Malek, Rahul Chaturvedi, Tim Song, services-dev
Hi servicification folks,

I wrote up a document about the services and what they'll be used for. Please give it a look and let me know if you have questions/concerns. Thank you! :)

Kyle


/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

Kyle Horimoto

unread,
Jun 28, 2017, 8:38:34 PM6/28/17
to Colin Blundell, John Abd-El-Malek, Rahul Chaturvedi, Tim Song, services-dev
Oops - I forgot to include the link. Here is the document: go/chrome-os-multi-device-apis
--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531

Colin Blundell

unread,
Jun 29, 2017, 11:58:16 AM6/29/17
to Kyle Horimoto, Colin Blundell, John Abd-El-Malek, Rahul Chaturvedi, Tim Song, services-dev
Hi Kyle,

That's a great design doc, thanks! I can't comment on it. (BTW, it looks like it's internal, whereas this is a public mailing list).

The reasoning in there is pretty solid from my POV. One point to mention is that "being in a service" != "being in a separate process" in general. Just because your code is servicified doesn't guarantee that it would be able to run in a separate service within the browser; there's a pretty high bar to adding processes to the browser. Of course, you might want it to run in use cases outside the browser, where the ability to run in a separate process would be valuable and utilized.

The remaining question from my POV is where these services would go. Foundational services doesn't feel right at this time, as others have mentioned (although I could see these services "graduating" to foundational services down the road if there's a lot of uptake). I'm going to start a separate thread about this topic right ... now.

Best,

Colin


/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

Kyle Horimoto

unread,
Jun 29, 2017, 1:44:16 PM6/29/17
to Colin Blundell, John Abd-El-Malek, Rahul Chaturvedi, Tim Song, services-dev
Thanks for doing a pass. I enabled comments - sorry for forgetting that before!

Thanks for the heads-up regarding the being in a different process. Please cc tengs@ and myself on the thread about non-foundational services :)

Cheers,
Kyle


/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

Kyle Horimoto

unread,
Jul 5, 2017, 2:53:11 PM7/5/17
to Colin Blundell, John Abd-El-Malek, Rahul Chaturvedi, Tim Song, services-dev
Hi Servicification folks,

Thanks for all the great feedback - I've responded to all the comments on my document. Just an FYI - in response to some comments, we've changed the naming of the proposed services from CryptAuth API and ProximityAuth API to DeviceSync API and SecureChannel API.

Does anyone have any additional concerns? Once we wrap up the discussion of where to place non-foundational services, am I free to start implementation?

Thanks for your help! :)
Kyle

Rahul Chaturvedi

unread,
Jul 5, 2017, 2:59:39 PM7/5/17
to Kyle Horimoto, Colin Blundell, John Abd-El-Malek, Tim Song, services-dev, Ken Rockot
It mostly lgtm. Though, as I mentioned on the doc and offline, my preference would be for this to be under one //services/opt/multidevice service, with two interfaces for the two pieces of functionality that it offers. I am concerned about flooding //services/opt (or //components, or where ever we put this service(s)) being more of a detriment than the advantages having these as separate services buy us. I also see services as a higher level abstraction than just an API. One key example is the Device service, where we plan on keeping completely disparate interfaces, that just happen to all deal with devices.

This isn't a particularly strong opinion though, so I'll defer to the opinion of other folks on this thread. John, Ken and Colin will probably have stronger feelings about this :)

Tim Song

unread,
Jul 5, 2017, 3:23:39 PM7/5/17
to Rahul Chaturvedi, Kyle Horimoto, Colin Blundell, John Abd-El-Malek, services-dev, Ken Rockot
I wouldn't oppose having the two interfaces under the same service, but would doing so make modularization more difficult?

As mentioned in the doc comments, one use case we have for EasyUnlock is depending on only the SecureChannel API for login (and not the CryptAuth API). Would having both APIs being under the same service hinder dependencies management?

Colin Blundell

unread,
Jul 6, 2017, 7:47:00 AM7/6/17
to Tim Song, Rahul Chaturvedi, Kyle Horimoto, Colin Blundell, John Abd-El-Malek, services-dev, Ken Rockot
On Wed, Jul 5, 2017 at 9:23 PM Tim Song <te...@chromium.org> wrote:
I wouldn't oppose having the two interfaces under the same service, but would doing so make modularization more difficult?

It would allow for introducing code dependencies between the two implementations and would make it less natural (and potentially more cumbersome) to move to a world where you swap in a different impl for one but not both of the interfaces. How hypothetical is that use case? If it's really hypothetical, I would just put them in the same place now and worry about that hypothetical issue if it ever becomes concrete.


As mentioned in the doc comments, one use case we have for EasyUnlock is depending on only the SecureChannel API for login (and not the CryptAuth API). Would having both APIs being under the same service hinder dependencies management?

It's trivial for a consumer to just connect to the SecureChannel interface and not the CryptAuth interface. Is there a particular dependency management issue that you're thinking about here?
 


/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.
--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531

Colin Blundell

unread,
Jul 6, 2017, 7:49:25 AM7/6/17
to Kyle Horimoto, Colin Blundell, John Abd-El-Malek, Rahul Chaturvedi, Tim Song, services-dev
On Wed, Jul 5, 2017 at 8:53 PM Kyle Horimoto <khor...@google.com> wrote:
Hi Servicification folks,

Thanks for all the great feedback - I've responded to all the comments on my document. Just an FYI - in response to some comments, we've changed the naming of the proposed services from CryptAuth API and ProximityAuth API to DeviceSync API and SecureChannel API.


Thanks, these names are much better IMO.
 
Does anyone have any additional concerns?

I have no further concerns.
 
Once we wrap up the discussion of where to place non-foundational services, am I free to start implementation?


It seems like that shed isn't going to get repainted at this time, so you could go ahead and follow the example of //components/printing/service. It will be easy enough to move stuff around in the future if/as we see fit.
 

/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.
--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531

Tim Song

unread,
Jul 6, 2017, 4:44:31 PM7/6/17
to Colin Blundell, Rahul Chaturvedi, Kyle Horimoto, John Abd-El-Malek, services-dev, Ken Rockot
You're right. Once the main servicification and interface work is done, it shouldn't be difficult to split the service if desired.

We're go ahead with what Ruhul suggested and make a service with two interfaces.


/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.
--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531

John Abd-El-Malek

unread,
Jul 6, 2017, 8:01:49 PM7/6/17
to Tim Song, Colin Blundell, Rahul Chaturvedi, Kyle Horimoto, services-dev, Ken Rockot
I'm wondering: of all the users of these two interfaces, how many will always be in the same process as the implementation? i.e. why is mojo being used here?

Kyle Horimoto

unread,
Jul 6, 2017, 8:19:56 PM7/6/17
to John Abd-El-Malek, Tim Song, Colin Blundell, Rahul Chaturvedi, services-dev, Ken Rockot
On Thu, Jul 6, 2017 at 5:01 PM, John Abd-El-Malek <j...@chromium.org> wrote:
I'm wondering: of all the users of these two interfaces, how many will always be in the same process as the implementation? i.e. why is mojo being used here?
Some of them (e.g., tethering) are likely to be in the same process. However, we already have one confirmed client who wishes to call this from ARC++, and there are plans to move the log-in screen out of the browser process, meaning that EasyUnlock will also call these APIs from another process.

John Abd-El-Malek

unread,
Jul 7, 2017, 10:58:36 AM7/7/17
to Kyle Horimoto, Tim Song, Colin Blundell, Rahul Chaturvedi, services-dev, Ken Rockot
Is the goal that all consumers would use the mojo interface, or will the in-process ones use C++ as before?

Kyle Horimoto

unread,
Jul 7, 2017, 1:40:08 PM7/7/17
to John Abd-El-Malek, Tim Song, Colin Blundell, Rahul Chaturvedi, services-dev, Ken Rockot
We were planning on having all clients use the interface to ensure that all calls go through the same flow (i.e., to reduce the possible points of failure as well as the maintenance burden). Is this a bad idea due to the overhead we'd incur using Mojo?

John Abd-El-Malek

unread,
Jul 10, 2017, 4:41:00 PM7/10/17
to Kyle Horimoto, Tim Song, Colin Blundell, Rahul Chaturvedi, services-dev, Ken Rockot
This shouldn't be very frequent that the small overhead of an in-process mojo call makes a difference; I agree it would be better to have one unified code path.

Colin Blundell

unread,
Jul 11, 2017, 2:19:47 AM7/11/17
to John Abd-El-Malek, Kyle Horimoto, Tim Song, Colin Blundell, Rahul Chaturvedi, services-dev, Ken Rockot
On Mon, Jul 10, 2017 at 10:41 PM John Abd-El-Malek <j...@chromium.org> wrote:
This shouldn't be very frequent that the small overhead of an in-process mojo call makes a difference; I agree it would be better to have one unified code path.

+1 to the latter point (I'm not really qualified to speak to the former point in this particular case, but in any case it's usually possible to design the API surface and usage model *such that* the asynchronicity isn't on a performance-critical path). I think that the main reason that John was asking was that if the C++ code is still going to be directly accessed by browser process consumers, it undercuts the idea of these features being services (rather than just features that get wrapped in a Mojo interface for access from other processes).
 



/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.
--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531



--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531

Colin Blundell

unread,
Jul 13, 2017, 6:51:34 AM7/13/17
to Colin Blundell, John Abd-El-Malek, Kyle Horimoto, Tim Song, Rahul Chaturvedi, services-dev, Ken Rockot
Hi Kyle and Tim,

Apologies if this topic has been discussed upthread, but which embedders will these features be used by in the near term? Will it only be Chrome? (i.e., only //chrome would connect to these services)? If so, per the non-foundational services thread that you're CC'd on, //chrome/services seems like the best place to host the services at this time. If it's only ChromeOS, we could potentially even put it somewhere more specific (perhaps //chromeos/services? although I'm not very familiar with where //chromeos sits in the layercake).

Best,

Colin 

James Cook

unread,
Jul 13, 2017, 10:24:19 PM7/13/17
to Colin Blundell, John Abd-El-Malek, Kyle Horimoto, Tim Song, Rahul Chaturvedi, services-dev, Ken Rockot
I think this has been discussed in a different thread, but //chromeos was originally intended for very low-level code that talks directly to system daemons or hardware. Even if a service is intended only for Chrome OS, I think it should sit near higher-level code (//chrome/services or //components/<something> or someplace "higher up" in the tree).

Colin 



/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.
--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531



--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531



--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531

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

To post to this group, send email to servic...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/CAMGE5NEQ2V_9LQjXG4sSk27oSxocoEPjNFvUFdn4N7PsCbhCfw%40mail.gmail.com.

Kyle Horimoto

unread,
Jul 14, 2017, 1:30:39 PM7/14/17
to James Cook, Colin Blundell, John Abd-El-Malek, Tim Song, Rahul Chaturvedi, services-dev, Ken Rockot
These services will only be used by ChromeOS - correct. Should we place the service in our component for now?

Colin Blundell

unread,
Jul 17, 2017, 3:32:10 AM7/17/17
to Kyle Horimoto, James Cook, Colin Blundell, John Abd-El-Malek, Tim Song, Rahul Chaturvedi, services-dev, Ken Rockot
On Fri, Jul 14, 2017 at 7:30 PM Kyle Horimoto <khor...@chromium.org> wrote:
These services will only be used by ChromeOS - correct. Should we place the service in our component for now?

I would suggest putting them in //chrome/services. Why were your features developed as components rather than in //chrome initially?
 

Colin 



/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.
--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531



--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531



--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531

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

To post to this group, send email to servic...@chromium.org.

Rahul Chaturvedi

unread,
Jul 17, 2017, 10:41:01 AM7/17/17
to Colin Blundell, Kyle Horimoto, James Cook, John Abd-El-Malek, Tim Song, services-dev, Ken Rockot
We've spoken about this a few times; these are services we want to access from outside the browser hence //chrome/* doesn't make sense for them.
Given the state of the discussion with non-quite-foundational services, I would just vote to put this in //components/multidevice/service for now and move it later to wherever makes sense.

This has been stuck on a bikeshed for quite a while now.

Colin 



/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.
--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531



--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531



--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531

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

To post to this group, send email to servic...@chromium.org.

Kyle Horimoto

unread,
Jul 17, 2017, 12:53:59 PM7/17/17
to Rahul Chaturvedi, Colin Blundell, James Cook, John Abd-El-Malek, Tim Song, services-dev, Ken Rockot
Sounds good - I'll be implementing them in //components/multidevice/service. Thanks everyone! :)

Colin Blundell

unread,
Jul 18, 2017, 12:52:21 PM7/18/17
to Rahul Chaturvedi, Colin Blundell, Kyle Horimoto, James Cook, John Abd-El-Malek, Tim Song, services-dev, Ken Rockot
On Mon, Jul 17, 2017 at 4:41 PM Rahul Chaturvedi <r...@chromium.org> wrote:
We've spoken about this a few times; these are services we want to access from outside the browser hence //chrome/* doesn't make sense for them.

I had indeed forgotten about the "access from the login/lock screen" use case, which is compelling. Thanks for reminding me.
 
Given the state of the discussion with non-quite-foundational services, I would just vote to put this in //components/multidevice/service for now and move it later to wherever makes sense.


Sure, that sounds good given that it will be easy enough to move later and we're clearly not going to come to immediate resolution on that thread.
 
This has been stuck on a bikeshed for quite a while now.


FWIW, feel free to ping if you feel that an issue is taking too long to resolve.

Best,

Colin
 
Colin 



/rkc

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

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.

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

To post to this group, send email to servic...@chromium.org.
--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531



--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531



--
Kyle Horimoto | Software Engineer | khor...@google.com | 310-938-8531

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

To post to this group, send email to servic...@chromium.org.
Reply all
Reply to author
Forward
0 new messages