Caretaker is a set of services (“Caretaker services”) that make the user’s life easy in various ways. These services simplify the setup and config of their smart feature phone by providing a way to manage the device remote (over the web) through desktop browser. These services would be based on Mozilla’s Firefox Accounts & cloud services. Example services are back and restore of contacts, editing phone settings remotely (eg: wallpaper), push address of location to navigation app. This bug is used to discuss architecture for the overall service.

Below is what we are capturing in Architecture doc: Table of contents 1 Introduction 4 1.1 Scope 4 1.2 Intended Audience 4 1.3 Overview 4 1.3.1 Target User Demographic 4 1.3.2 Service Value (& subscription) 5 2 Functional Requirements 5 3 Architectural Representation 9 3.1 System Context 9 3.2 Interfaces 9 3.3 Web Server Interfaces 9 3.4 Data Sync Interfaces 10 3.5 Block/Functional diagram 10 4 Deployment Scenarios 12 5 Sequence Flow/Diagrams 12 6 Technology choices 13 6.1 Recommendation 13 7 Assumptions 13 8 Environment Configuration 13 8.1 Hardware Requirements 13 8.2 Software Requirements 13 9 Open Source 13 10 Software Limitations 13

1. DB Evaluation: The PostgreSql that is currently getting used for storing Bookmarks, password etc will be reused for storing Caretaker data as well. This would require existing Storage Service to be enhanced so that it is able to handle Caretaker data as well while interacting with DB. 2. Device Notification To notify change on DB done by Caretaker, Mozilla notification service is getting evaluated. 3. Technology choices On backend side we have 3 choices - Python, Java/Spring, Node JS. These technologies shall be evaluated and final one will be recommended, to be used on server side. A light POC has been done using which Python code was invoked (functionally) using Java code. On frontend side also technologies are getting evaluated

(In reply to Shiv Raturi from comment #1) > Below is what we are capturing in Architecture doc: > Table of contents > 1 Introduction 4 > 1.1 Scope 4 > 1.2 Intended Audience 4 > 1.3 Overview 4 > 1.3.1 Target User Demographic 4 > 1.3.2 Service Value (& subscription) 5 > 2 Functional Requirements 5 > 3 Architectural Representation 9 > 3.1 System Context 9 > 3.2 Interfaces 9 > 3.3 Web Server Interfaces 9 > 3.4 Data Sync Interfaces 10 > 3.5 Block/Functional diagram 10 > 4 Deployment Scenarios 12 > 5 Sequence Flow/Diagrams 12 > 6 Technology choices 13 > 6.1 Recommendation 13 > 7 Assumptions 13 > 8 Environment Configuration 13 > 8.1 Hardware Requirements 13 > 8.2 Software Requirements 13 > 9 Open Source 13 > 10 Software Limitations 13 Please also include user data encryption....a hugely important topic for Mozilla. Thanks, tony

Hi Tony, Do you mean FX_018 requirement (""Encryption of User data stored in server") in FirefoxServices sheet?

(In reply to Shiv Raturi from comment #4) > Hi Tony, > Do you mean FX_018 requirement (""Encryption of User data stored in server") > in FirefoxServices sheet? Both on the server and over the sync transfer mechanism.

(In reply to Tony Appleton from comment #5) > (In reply to Shiv Raturi from comment #4) > > Hi Tony, > > Do you mean FX_018 requirement (""Encryption of User data stored in server") > > in FirefoxServices sheet? > > Both on the server and over the sync transfer mechanism. Hi Tony, Does that mean encrypted data needs to be sent on Webservice interface (Desktip <--> Server) and Data sync interface (Device <--> Server)?

(In reply to Tony Appleton from comment #5) > (In reply to Shiv Raturi from comment #4) > > Hi Tony, > > Do you mean FX_018 requirement (""Encryption of User data stored in server") > > in FirefoxServices sheet? > > Both on the server and over the sync transfer mechanism. Hi Tony, Does that mean encrypted data needs to be sent on Webservice interface (Desktop <--> Server) and Data sync interface (Device <--> Server)?

Requesting Ravi to respond to question in Comment 7. Thanks, tony

In progress architecture document. Need inputs from Michiel on components being used.

(In reply to Shiv Raturi from comment #9) > Created attachment 8670243 [details] > FxServices_Application_Architecture_Draft1.0_06Oct15.docx > > In progress architecture document. > Need inputs from Michiel on components being used. Asking Ravi for first round review..

(In reply to Shiv Raturi from comment #9) > Created attachment 8670243 [details] > FxServices_Application_Architecture_Draft1.0_06Oct15.docx > > In progress architecture document. > Need inputs from Michiel on components being used. Hi Shiv, Thanks for this document, very welcome contributions! Some of the features you describe are about Data Sync on FxOS, and I don't think the development of these components is on the FxOS Data Sync roadmap yet. So we need to get some vision on how your proposals can fit into the bigger plan, to make sure your work can be reused in the general Data Sync implementation for Firefox OS. The product manager for FxOS Data Sync is Preeti Sanketh, please ask her to include these proposed features into her roadmap, so she can decide who should implement which components, and when.

I've uploaded Shiv's word document to Google Docs so that I (and others can comment on it). Here's the link: https://docs.google.com/document/d/1vqUDE1fWlJHn5VxUj-9RWZ-dXSQ9ptB6cktsaIUh7I0/edit?usp=sharing

Shiv's document is a great starting point for trying to nail down exactly what we want caretaker to be. I've added a lot of comments on the google docs version https://docs.google.com/document/d/1vqUDE1fWlJHn5VxUj-9RWZ-dXSQ9ptB6cktsaIUh7I0/edit?usp=sharing

Have added comments into the document pointed by David Flanagan in comment 12. Agree, lets use that to converge on architecture. Following bugs are filed to track specific items apart from the overall architecture which is current bug 1) Bug 1211781 - Overall architecture of Caretaker (current bug) 2) Bug 1212182 - [Redsquare] Contacts Sync for FirefoxOS 3) Bug 1212217 - [Redsquare] Security and Privacy review of Contacts Sync for FirefoxOS

(In reply to Shiv Raturi from comment #7) > Does that mean encrypted data needs to be sent on Webservice interface > (Desktop <--> Server) and Data sync interface (Device <--> Server)? Adding Paul Theriault from security team to comment on this. We should be consistent with Mozilla policies.

(In reply to rdandu from comment #15) > (In reply to Shiv Raturi from comment #7) > > Does that mean encrypted data needs to be sent on Webservice interface > > (Desktop <--> Server) and Data sync interface (Device <--> Server)? > > Adding Paul Theriault from security team to comment on this. We should be > consistent with Mozilla policies. I'd defer to our web services security people on this - my knowledge of Sync and FirefoxAccounts architecture is pretty limited. My understanding of Sync though was that Mozilla doesnt have access to the data. IE The data is transferred encrypted, end-to-end, and is completely opaque to Mozilla. I've no idea how things like Loop/Hello manage contacts though, and if we follow the same sort of zero knowledge approach. This will obviously have a pretty big impact on the types of services Mozilla can provide, and the architecture of any system. For more info on Sync security, see also https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol#security-analysis

(In reply to Michiel de Jong [:michielbdejong] from comment #11) > (In reply to Shiv Raturi from comment #9) > > Created attachment 8670243 [details] > > FxServices_Application_Architecture_Draft1.0_06Oct15.docx > > > > In progress architecture document. > > Need inputs from Michiel on components being used. > > Hi Shiv, > > Thanks for this document, very welcome contributions! Some of the features > you describe are about Data Sync on FxOS, and I don't think the development > of these components is on the FxOS Data Sync roadmap yet. So we need to get > some vision on how your proposals can fit into the bigger plan, to make sure > your work can be reused in the general Data Sync implementation for Firefox > OS. > > The product manager for FxOS Data Sync is Preeti Sanketh, please ask her to > include these proposed features into her roadmap, so she can decide who > should implement which components, and when. Hi Michiel, After getting inputs from you for the 2.5 work that your team is working, my expectations from Data sync interface is that Import bookmarks functionality should be working. Rest we will develop.

(In reply to Michiel de Jong [:michielbdejong] from comment #11) > (In reply to Shiv Raturi from comment #9) > > Created attachment 8670243 [details] > > FxServices_Application_Architecture_Draft1.0_06Oct15.docx > > > > In progress architecture document. > > Need inputs from Michiel on components being used. > > Hi Shiv, > > Thanks for this document, very welcome contributions! Some of the features > you describe are about Data Sync on FxOS, and I don't think the development > of these components is on the FxOS Data Sync roadmap yet. So we need to get > some vision on how your proposals can fit into the bigger plan, to make sure > your work can be reused in the general Data Sync implementation for Firefox > OS. > > The product manager for FxOS Data Sync is Preeti Sanketh, please ask her to > include these proposed features into her roadmap, so she can decide who > should implement which components, and when. Hi Michiel, After getting inputs from you for the 2.5 work that your team is working, my expectations from Data sync interface is that Import bookmarks functionality should be working. Rest we will develop. In parallel we are also evaluating Kinto. If we use kinto then syncserver would not be required.

Many comments on document has been incorporated. Remaining are in progress.

All comments have been incorporated. Please review the remaining sections. To DO/In Progress : 1. Web Server Interfaces messages details 2. Data Sync Interfaces messages details 3. Block Level Diagram might require changes based on Kinto evaluation 4 Database Schema for data to be stored 5 Sequence Diagrams for all functional requirements 6. Assumptions (if any other than what is captured in SOW)

Someone (Shiv, I think) made a lot of edits to the google doc, which made most of my comments on the doc disappear. But those comments were my contribution to a meeting today about the architecture. So, here's what I've done: - I made the google doc read-only - I accepted all of the edits - I made a new copy of the document, with the edits accepted, and made that one commentable - I reverted the original back to the last version I modified so that my comments would still be available. The new, commentable, version of the document is here: https://docs.google.com/document/d/1dioYRVKpoJLgZ3055fzsUgTpgoIsI2lGpx2-tzz42Ao/edit The original, now read-only version is here: https://docs.google.com/document/d/1vqUDE1fWlJHn5VxUj-9RWZ-dXSQ9ptB6cktsaIUh7I0/edit# I'm a newbie to google docs, so I'm not sure what the best workflow is here. I'm surprised that Shiv's proposed edits would make my comments disappear completely, but I couldn't find them anymore.

Hi David, Shiv marked the your and my comments as 'resolved' since he incorporated them into the document. Resolving them makes them disappear. Shiv, We would like to discuss the items a more as we include more experts in these discussions. So you might want to leave the comments in for a week or so, until more people have a chance to comment and digest the information. You can leave a comment in when you incorporate it, and we can go through together in a week, and explicitly click 'resolve' which will get rid of the comments.

Hi Ravi, I'm also new thos google docs. I didn't know that marking comments resolved will remove them permanently. Hi David, Thanks for creating a new editable document as with these many changes it was becoming difficult to see the changes. Hi All, Please review the updated doc for the changes. https://docs.google.com/document/d/1dioYRVKpoJLgZ3055fzsUgTpgoIsI2lGpx2-tzz42Ao/edit

Hi Ravi, I'm also new to google docs so didn't know that marking comments resolved will remove them permanently. I'll take care of this for future comments. Hi David, Thanks for creating a new editable document as with these many changes it was becoming difficult to see the new changes. Hi All, Please review the updated doc for the changes. https://docs.google.com/document/d/1dioYRVKpoJLgZ3055fzsUgTpgoIsI2lGpx2-tzz42Ao/edit I'm working on Sequence diagram now for "Call Logs - GET/ADD"

Updated data sync interface and websevrice interface for Call Logs feature. Please review.

Hi Shiv, (In reply to Shiv Raturi from comment #25) > Updated data sync interface and websevrice interface for Call Logs feature. > Please review. I'll wait with technical review of the data sync part until Ravi Dandu and Preeti Sanketh complete their discussion about these features at the product design/planning level, hope that's ok.

Travis, you and I need to review and discuss this architecture document from the FxOS team for the Caretaker service proposal. The proposal is for a contacting firm to build a service that: 1) Integrates with FxA and Sync 2) Would be run by your team

Changes made: 1. Various approaches evaluated and recommendation made 2. Data sync interface and Web Service interface defined for CallLogs 3. Technologies finalized stakeholders kindly provide your comments so that we could kick start our development in parallel.

I've added small corrections and some comments to the chapter "Interfaces"

Ravi and Preeti asked me to review the architecture document. 1) IIUC, the current plan is for large pieces of the Caretaker back end server and Web front end to be developed entirely by a contractor. I have general concerns about the longer term development and maintenance of the Caretaker service. After the contract ends, who is going to be responsible for maintaining Caretaker? The Firefox Cloud Services team is not resourced to do this, both in terms of people and skill set. I noticed the proposed language is Java, and we have no back end services developed in Java. 2) The architecture also requires a few new components from the Firefox Cloud Services team (e.g., Kinto, Syncto proxy, new Sync back end services). The success of this proposal depends on if those can be built in the required time frame. Firefox Cloud Services has limited resources and a full backlog of competing priorities.

(In reply to Chris Karlof [:ckarlof] from comment #30) > Ravi and Preeti asked me to review the architecture document. > > 1) IIUC, the current plan is for large pieces of the Caretaker back end > server and Web front end to be developed entirely by a contractor. I have > general concerns about the longer term development and maintenance of the > Caretaker service. After the contract ends, who is going to be responsible > for maintaining Caretaker? The Firefox Cloud Services team is not resourced > to do this, both in terms of people and skill set. I noticed the proposed > language is Java, and we have no back end services developed in Java. > > 2) The architecture also requires a few new components from the Firefox > Cloud Services team (e.g., Kinto, Syncto proxy, new Sync back end services). > The success of this proposal depends on if those can be built in the > required time frame. Firefox Cloud Services has limited resources and a full > backlog of competing priorities. Hi Chris, Thanks for your inputs. I've proposed 3 architecture approaches in doc & added their pros and cons. The final recommended one doesn't require Kinto or Sync Server. The recommended approach mentions that with Caretaker App Server alone this can be achieved. Could you please provide your review comments on doc?

All changes done for CallLogs feature.

Hi Michiel, Davi & Chris, Kindly provide your review comments on the Architecture document so that we could start our implementation based on proposed architecture and technologies.

Hi Shiv, My main comment: Do not use data sync or any kind of database to store user data outside the phone. Storing data in the cloud (in a type of database, whether Sync or Kinto or otherwise) is not feasible for version 1. The reason is simple: We will not have end-to-end encryption implemented until well into 2016, and we don't want to store user data unencrypted, because privacy is one of Mozilla's important mission goals. So the Caretaker server should communicate with the RedSquare device directly and in real-time, and not store any data outside the phone. Data sync can come to RedSquare at a later stage, but not yet (Ravi and Preeti are already talking about if, how and when this will happen). Since you will not be able to use data sync for Caretaker, I advise you to use screen sharing and/or push notifications, and also to have a look at how BuddyUp [1] does it (very similar to Caretaker in some respects). Cheers! Michiel. [1] https://marketplace.firefox.com/app/buddyup/

Hi Michiel, With no DB is place we need to keep everything in memory. Below is what will be technically possible (but a lot time consuming ) to cater this. So, solution without a DB in place would not be recommended as it will result in lot of delays. For every communication between server and device, 4 request response cycles data is flowing between device and server. So, we must have a DB in place to keep data. We can discuss about basic encryption on server to store data on DB. And Server & Device can communicate over https. Hi Ravi, Could you please share your opinion on this?

Flow between server and device without DB. Not recommended.

Hi All, The Architecture document is final from my side with all internal comments incorporated.

Hi Shiv, So did you incorporate my suggestion of using a single Push notification followed by WebRTC between Caretaker UI and the RedSquare device? Didn't hear back from you about that. Would be a nice way to cut out the server-side code altogether, and do it all in HTML5. You can have a look at how the Firefox Hello loop server does it for instance.

I think that Chris and Michiel have spoken clearly in comment #30 and comment #34 about the problems with the proposed architecture and implementation. I don't have anything to add (nor am I qualified to add) to those comments. I will comment that the functional requirements listed in the architecture doc still strike me as not being fully thought through. For example: - the doc does not seem to specify how often the device will sync with the server. Does it have to contact a server every time the user makes or receives a call or changes an alarm or edits a contact? - the doc does not seem to specify how conflicts will be resolved. What happens if a contact is being edited locally and remotely at the same time? Who wins? How do we enforce that. - I still think that the ability to send text messages via the cloud is insanely dangerous. At a minimum there is going to have to be a verification step where the user is prompted and gets to review the text before it is sent. The architecture document does not have any discussion of this or of what the UX will be on-device if a caretaker is trying to send a text remotely. Maybe the user sees a notification of the request to send a text, and tapping on the notification launches the sms app and lets the view the draft message and push the send button? This is a huge amount of work, and as a feature, it seems very under-specified. - The part about remote management of settings has things that don't make much sense either... Turning on airplane mode remotely would immediately disconnect the phone, which doesn't make sense. Querying the battery level remotely probably doesn't make sense since that is a device query, not a settings db query. We're not proposing that the phone should send its current battery status to a sync server every 5 minutes are we? And what is the "Manage Homescreen" line doing under settings? This phone will have a completely different homescreen that is very customizable, but is not customized via Settings. If homescreen management is part of the Caretaker spec, that will be a huge new feature, at least as complicated as all the other settings combined, and it should be at a higher level along with contacts, call logs, etc.

(In reply to Chris Karlof [:ckarlof] from comment #30) > Ravi and Preeti asked me to review the architecture document. > > 1) IIUC, the current plan is for large pieces of the Caretaker back end > server and Web front end to be developed entirely by a contractor. I have > general concerns about the longer term development and maintenance of the > Caretaker service. After the contract ends, who is going to be responsible > for maintaining Caretaker? The Firefox Cloud Services team is not resourced > to do this, both in terms of people and skill set. I noticed the proposed > language is Java, and we have no back end services developed in Java. > [SHIV]: As per Architecture doc review meeting we are waiting for the list of technologies that are getting uses in Firefox services. We will add those in Architecture doc. Slide 2 in https://docs.google.com/presentation/d/1vujRNhO1di0BqCxl5AZCWL58auhgCZlB8gH7dGpIzCY/edit#slide=id.gd009d98b4_0_0 > 2) The architecture also requires a few new components from the Firefox > Cloud Services team (e.g., Kinto, Syncto proxy, new Sync back end services). > The success of this proposal depends on if those can be built in the > required time frame. Firefox Cloud Services has limited resources and a full > backlog of competing priorities. [SHIV]: Proposed architecture require Syncto, FxAuth server and Token server only.

(In reply to Michiel de Jong [:michielbdejong] from comment #34) > Hi Shiv, > > My main comment: Do not use data sync or any kind of database to store user > data outside the phone. > > Storing data in the cloud (in a type of database, whether Sync or Kinto or > otherwise) is not feasible for version 1. The reason is simple: We will not > have end-to-end encryption implemented until well into 2016, and we don't > want to store user data unencrypted, because privacy is one of Mozilla's > important mission goals. > > So the Caretaker server should communicate with the RedSquare device > directly and in real-time, and not store any data outside the phone. > > Data sync can come to RedSquare at a later stage, but not yet (Ravi and > Preeti are already talking about if, how and when this will happen). Hi Michiel, With no DB is place we need to keep everything in memory. Attachment shows what will be technically possible (but time consuming ) to cater this. So, solution without a DB in place would not be recommended as it will result in lot of delays. For every communication between server and device, 4 request response cycles data is flowing between device and server. So, we must have a DB in place to keep data. We can implement basic encryption on server to store data on DB. And Server & Device can communicate over https. > Since you will not be able to use data sync for Caretaker, I advise you to > use screen sharing and/or push notifications, and also to have a look at how > BuddyUp [1] does it (very similar to Caretaker in some respects). > > Cheers! > Michiel. > > [1] https://marketplace.firefox.com/app/buddyup/ Push notification has been taken tn the Architecture that would be required. For screen sharing Alexey can provide comments from device side. I have below comments on it: 1. Since there will be no caretaker server so device data will not get backed up ( as required by Mozilla) 2. device user has to be online for the changes done by Caretaker. Currently Architecture supports offline changes 3. Elderly person needs to be intelligent enough to accept peer WebRTC call; pass control to Caretaker etc. 4. Bandwidth requirement in case of WebRTC communication will be comparatively higher than Cloud solution. Cellular data usage of device will be high as all changes need to be done via WebRTC session. 5. Processing power of the device also needs to be high 6. The proposed architecture can support 1 million & more users with their minimal data usage. With WebRTC calls managing 1 million sessions will be challenge. Alexey, Can you please comment on screen sharing from Device perspective?

(In reply to Michiel de Jong [:michielbdejong] from comment #38) > Hi Shiv, > > So did you incorporate my suggestion of using a single Push notification > followed by WebRTC between Caretaker UI and the RedSquare device? Didn't > hear back from you about that. Would be a nice way to cut out the > server-side code altogether, and do it all in HTML5. You can have a look at > how the Firefox Hello loop server does it for instance. Hi Michel, Kindly find my inputs on comment no 41 for this.

(In reply to Shiv Raturi from comment #41) > With no DB is place we need to keep everything in memory. Attachment shows > what will be technically possible (but time consuming ) to cater this. > So, solution without a DB in place would not be recommended as it will > result in lot of delays. For every communication between server and device, > 4 request response cycles data is flowing between device and server. > So, we must have a DB in place to keep data. We can implement basic > encryption on server to store data on DB. And Server & Device can > communicate over https. Server side encryption (where the keys are accessible by the server operator) doesn't solve the privacy problem at all. > 4. Bandwidth requirement in case of WebRTC communication will be > comparatively higher than Cloud solution. Cellular data usage of device will > be high as all changes need to be done via WebRTC session. Why would bandwith needed be higher with webRTC? You're transmitting roughly the same data no? > 5. Processing power of the device also needs to be high Data channels are lightweight. Not much more than https. > 6. The proposed architecture can support 1 million & more users with their > minimal data usage. With WebRTC calls managing 1 million sessions will be > challenge. Do you think there's a need for 1 million simultaneous sessions?

Hi Shiv, We are starting to have a better view of how data sync will work on Firefox OS in 2016. Let's have a (video-)chat about how RedSquare fits into that. I'll ping you via email.

(In reply to [:fabrice] Fabrice Desré from comment #43) > (In reply to Shiv Raturi from comment #41) > > > With no DB is place we need to keep everything in memory. Attachment shows > > what will be technically possible (but time consuming ) to cater this. > > So, solution without a DB in place would not be recommended as it will > > result in lot of delays. For every communication between server and device, > > 4 request response cycles data is flowing between device and server. > > So, we must have a DB in place to keep data. We can implement basic > > encryption on server to store data on DB. And Server & Device can > > communicate over https. > > Server side encryption (where the keys are accessible by the server > operator) doesn't solve the privacy problem at all. > I'm not encryption expert here but if we can use user password for encryption + decryption then this issue will get resolved. Some expert needs to comment on this. > > > 4. Bandwidth requirement in case of WebRTC communication will be > > comparatively higher than Cloud solution. Cellular data usage of device will > > be high as all changes need to be done via WebRTC session. > > Why would bandwith needed be higher with webRTC? You're transmitting roughly > the same data no? With WebRTC a session is established and bandwidth requirement is many folds. Without WebRTC we are just sending minimal HTTPS requests with minimal payload that has actually got modified on server. So from end user perspective his/her cellular data usage will be very less. > > 5. Processing power of the device also needs to be high > > Data channels are lightweight. Not much more than https. > > > 6. The proposed architecture can support 1 million & more users with their > > minimal data usage. With WebRTC calls managing 1 million sessions will be > > challenge. > > Do you think there's a need for 1 million simultaneous sessions? In theory yes there is requirement; so Architecture must support it. Giving an exmaple in one of our WebRTC projects we supported conferencing session for 30 users. The media goes via Media server. We required 8 GB memory and quad core processor to achieve that. Memory consumption went till 129%; bitrate on user side was 3.2 Mbps. Now how many sessions can be supported by Media server that creates a bottleneck for webRTC solution. So, if we think of WebRTC based solution then we need to know the performance figures of Media Server.

(In reply to Shiv Raturi from comment #41) > Alexey, > Can you please comment on screen sharing from Device perspective? Well, as far as I understand from the latest communication with Shiv and Irfan, Mozilla wants to have database for backup/restore of contacts and other userdata. Are we all in line with this? So, as far as I understand the idea is to keep some user data (like contacts & call log) in encrypted database on the server side. This data can be editable by the user when device is offline. The other caretaker cases (like setting up the E-mail settings, phone settings, setup alarms, etc.) will be available only when the device is online. I have some concerns about WebRTC, sharing phone screen and presenting it to caretaker. First of all WebRTC is not supported by Firefox OS for now: https://bugzilla.mozilla.org/show_bug.cgi?id=750011. Implementation of WebRTC on the device side is quite a huge task. Another concern is data usage. I suspect the traffic will be heavy if we follow this approach and probably the performance will not be acceptable. Considering that we need to transfer a very simple data between device and the server (like text messages) should we consider a simple push notification for initiating connection between server and after that use a simple REST protocol (or something other, but very simple) to send data back and forth between device and server.

(In reply to David Flanagan [:djf] from comment #39) > I think that Chris and Michiel have spoken clearly in comment #30 and > comment #34 about the problems with the proposed architecture and > implementation. I don't have anything to add (nor am I qualified to add) to > those comments. Provided inputs for these comments on my replies to these comments. > I will comment that the functional requirements listed in the architecture > doc still strike me as not being fully thought through. For example: > > - the doc does not seem to specify how often the device will sync with the > server. Comments incorporated in GEN-8 requirement. >Does it have to contact a server every time the user makes or > receives a call or changes an alarm or edits a contact? Comment incorporated in GEN-5 requirement. > - the doc does not seem to specify how conflicts will be resolved. What > happens if a contact is being edited locally and remotely at the same time? > Who wins? How do we enforce that. Comment incorporated in GEN-9 requirement. > > - I still think that the ability to send text messages via the cloud is > insanely dangerous. At a minimum there is going to have to be a verification > step where the user is prompted and gets to review the text before it is > sent. The architecture document does not have any discussion of this or of > what the UX will be on-device if a caretaker is trying to send a text > remotely. Maybe the user sees a notification of the request to send a text, > and tapping on the notification launches the sms app and lets the view the > draft message and push the send button? This is a huge amount of work, and > as a feature, it seems very under-specified. I think this doesn't come into Architecture doc scope whic is taking care of server aspects and not how a feature is implemented on device app. This comment is valid for device "Messages" application or for UX doc. http://r1l8an.axshare.com/ section 5.0 > > - The part about remote management of settings has things that don't make > much sense either... Turning on airplane mode remotely would immediately > disconnect the phone, which doesn't make sense. Accepted, airoplane settings removed as per comments in SETTINGS_GET-1 Querying the battery level > remotely probably doesn't make sense since that is a device query, not a > settings db query. We're not proposing that the phone should send its > current battery status to a sync server every 5 minutes are we? Accepted, battery settings removed as per comments > the "Manage Homescreen" line doing under settings? This phone will have a > completely different homescreen that is very customizable, but is not > customized via Settings. If homescreen management is part of the Caretaker > spec, that will be a huge new feature, at least as complicated as all the > other settings combined, and it should be at a higher level along with > contacts, call logs, etc. Accepted, "Manage Homescreen" settings removed as per comments

Incorporated all comments. For "User Data Security" I have added a section 8 "User Data Security". Contents will be added later.

Support for getting live data from Device also added. Live data will be required for specific cases like Wifi settings.

(In reply to Alexey Yakimov from comment #46) > Well, as far as I understand from the latest communication with Shiv and > Irfan, Mozilla wants to have database for backup/restore of contacts and > other userdata. Are we all in line with this? Yes, this is basically what we call data sync. We are implementing it for all Firefox OS devices. Harman's contributions to this project are very welcome! We can organize these contributions in such a way that Harman create pull requests, and Mozilla reviews them. It's important that we discuss who-does-what before you start, so that 1) your contributions help Mozilla to launch data sync faster, and 2) the data sync architecture for RedSquare is in line with the data sync architecture for other Firefox OS devices (like Smart TV and smartphone), so that we don't have to maintain two incompatible implementations of the same functionalities. I'm having a video call with Shiv about this tomorrow. > > So, as far as I understand the idea is to keep some user data (like contacts > & call log) in encrypted database on the server side. This data can be > editable by the user when device is offline. That part is not entirely accurate, the data will be end-to-end encrypted (not just encrypted on the server side). The plan (which we will be discussing among the Data Sync team and Mozilla contributors next month) is to probably use WebCrypto Key Discovery for this: https://wiki.mozilla.org/Firefox_OS_Data_Sync#CryptoKey_and_CryptoKey_Discovery_API > > The other caretaker cases (like setting up the E-mail settings, phone > settings, setup alarms, etc.) will be available only when the device is > online. Sounds good. These data will also have to be end-to-end encrypted between the device and the user interface. That's why I suggested using WebRTC for this, the data travelling over WebRTC is end-to-end encrypted (peer-to-peer, not peer-to-server-to-peer). > > I have some concerns about WebRTC, sharing phone screen and presenting it to > caretaker. First of all WebRTC is not supported by Firefox OS for now: > https://bugzilla.mozilla.org/show_bug.cgi?id=750011. Implementation of > WebRTC on the device side is quite a huge task. mozRTCPeerConnection is available on FxOS (I just checked this using WebIDE). > Another concern is data usage. I suspect the traffic will be heavy if we > follow this approach and probably the performance will not be acceptable. I think there is a confusion here between "WebRTC" as a technology and "live video" as a payload. > Considering that we need to transfer a very simple data between device and > the server (like text messages) should we consider a simple push > notification for initiating connection between server and after that use a > simple REST protocol (or something other, but very simple) to send data back > and forth between device and server. WebRTC's built-in end-to-end encryption means the real-time case is much, much simpler than the data sync case. If you use a REST protocol here then you lose that benefit, so then you basically depend on WebCrypto Key Discovery not only for data sync, but also for the real-time case.

PFA the updated architecture document with Kinto server in use.

Updated architecture document with Kinto server in use.

Firefox OS is not being worked on