none
Challenge with API owners and caching/persisting data in Office apps RRS feed

  • Question

  • I've had conversations recently with two API owners both of whom have balked at my use of their API once they discover that the consuming app is Office (Excel) because their Ts & Cs restrict caching/persistence of API results.

    My opinion is that such a restriction is mostly futile and can only reasonably be enforced through passing-on and explaining such requirements to app customers.

    I've explained to the API owner on both occasions that replacing the data representation of an Excel table with an HTML table would overcome the owner's concern but does not circumvent almost equivalent functionality of then copying-and-pasting (for example) the HTML table in an Excel spreadsheet and manipulating it.

    Questions

    1. Have other folks encountered this challenge?
    2. How you resolved it?
    3. Tmk the JavaScript API provides no ability to constrain (dare I say, DRM) data bound to an Office document. Any plans for such functionality?
    4. Are there any best practices/approaches to mitigate it?

    I anticipate being stopped again later this week after the legal team of the owners of the API I'm using has had a chance to review my app and challenges my method of 'persisting' API data to a spreadsheet, it would be very helpful to have answers to some of the previous questions in order to argue my case.


    Thanks!


    Tuesday, October 23, 2012 9:14 PM

Answers

  • Hi Daz - I can see the api owner's point, they rely on people hitting their endpoint to maintain control of their data and don't want someone hoovering it all up and then hosting it themselves.

    As you point out any api caller could do this, and also that once displayed the user can usually scrape it out & save it locally in some form (I've seen people use camera + ocr to extract info from DRM's documents). Once the data is in Excel the user can delete your app and then proliferate the data. You can't encrypt it as the user has to be able to see/do reports on top of the data.

    We don't have immediate IRM plans, in fact we won't activate an app in a document with IRM applied (even with "execute code" allowed) as we decided to assume that an IRM's document is likely to contain data that you wouldn't want sent out to the network - we'll monitor customer feedback here for the next release.

    I would recommend that you discuss some additional controls with the api owners that might mitigate their concerns:

    1/ You could use the document settings object to timestamp the data & associate the app user - that way if the spreadsheet is used to proliferate the data with your app you'd at least be able to track it back to an (ab)user. To cope with your app being removed you can use a hidden cell/white on white text to hide the fingerprint but be aware that Trust Center Privacy Document Inspector does a pretty good job of identifying these things.

    2/ You could limit the amount of data that you will return into the spreadsheet (aggregate it or return the first x rows), again mitigation to the entire dataset being stolen

    3/ You can throttle the amount of data any one user is allowed to access over a period of time - again this would prevent total download

    4/ You can require that the user of your app make separate agreement with the api owner and then you could collect their license key at run time and use it to retrieve data.

    We assume that once the data has left the document through the app it can be proliferated over the network, the same applies to the api supplier's data - once it has left their server only legal agreements protect them (irrespective of any app model)

    I hope this helps....pc

    • Marked as answer by Daz Wilkin 2 Saturday, October 27, 2012 1:38 AM
    Friday, October 26, 2012 11:55 PM

All replies

  • Hi Daz Wilkin 2,

    Thank you for posting in the MSDN Forum.

    I'm consulting your issue with my colleague and you'll be informed if there's any reply.

    Thank you for your patient and understanding.

    Best regards,


    Quist Zhang [MSFT]
    MSDN Community Support | Feedback to us

    Thursday, October 25, 2012 10:34 AM
    Moderator
  • HTML5 standard has the Application cache API which should be helpful to your requirement. See a sample here: Apps for Office: Enable offline apps using browser caching

    Your question about third party Javascript library is kind of discussion, owner comment is the key.

    thanks.


    Forrest Guo | MSDN Community Support | Feedback to manager

    Friday, October 26, 2012 3:00 AM
    Moderator
  • No, this does not address my question.

    The problem is that API owners often require no caching / no persistence of their result data beyond the immediate use of the application.

    A common use case with Office apps (let's use Excel as the example) is to cache/persist API results on a spreadsheet in order that the user may crunch the data, graph it etc.

    The API owners with whom I've discussed Excel scenarios have both told me that transferring data to a spreadsheet contravenes their API Ts & Cs.

    Friday, October 26, 2012 4:25 PM
  • Hi Daz - I can see the api owner's point, they rely on people hitting their endpoint to maintain control of their data and don't want someone hoovering it all up and then hosting it themselves.

    As you point out any api caller could do this, and also that once displayed the user can usually scrape it out & save it locally in some form (I've seen people use camera + ocr to extract info from DRM's documents). Once the data is in Excel the user can delete your app and then proliferate the data. You can't encrypt it as the user has to be able to see/do reports on top of the data.

    We don't have immediate IRM plans, in fact we won't activate an app in a document with IRM applied (even with "execute code" allowed) as we decided to assume that an IRM's document is likely to contain data that you wouldn't want sent out to the network - we'll monitor customer feedback here for the next release.

    I would recommend that you discuss some additional controls with the api owners that might mitigate their concerns:

    1/ You could use the document settings object to timestamp the data & associate the app user - that way if the spreadsheet is used to proliferate the data with your app you'd at least be able to track it back to an (ab)user. To cope with your app being removed you can use a hidden cell/white on white text to hide the fingerprint but be aware that Trust Center Privacy Document Inspector does a pretty good job of identifying these things.

    2/ You could limit the amount of data that you will return into the spreadsheet (aggregate it or return the first x rows), again mitigation to the entire dataset being stolen

    3/ You can throttle the amount of data any one user is allowed to access over a period of time - again this would prevent total download

    4/ You can require that the user of your app make separate agreement with the api owner and then you could collect their license key at run time and use it to retrieve data.

    We assume that once the data has left the document through the app it can be proliferated over the network, the same applies to the api supplier's data - once it has left their server only legal agreements protect them (irrespective of any app model)

    I hope this helps....pc

    • Marked as answer by Daz Wilkin 2 Saturday, October 27, 2012 1:38 AM
    Friday, October 26, 2012 11:55 PM
  • Patrick

    This is very helpful.

    Thanks for taking the time to reply with such a well thought out and exhaustive list of suggestions.

    I really appreciate it.

    Daz

    Saturday, October 27, 2012 1:38 AM