How does date expiry work?
Date expiry information (and many other settings) are stored in the header block of the converted drmx or drmz file. The local date/time on the device is compared with the stored date/time and this is used to check for expiry. This is augmented by one or two other (undocumented) checks to minimize the chance of someone fiddling their device date subsequent to expiry, but is the core of the process (the details of implementation of these checks varies by platform and version of our software).
There are two options for date expiry:
(i) an explicit expiry date, e.g. 10th August 2016. This is the standard/default option. Once set in the secured document it cannot be changed and is stored on the end user’s device when they authorize the file. The only way to undo this on the end user’s device is to use the Remove Authorization option in Javelin for the file in question, or to issue a new version of the file with a different documentID so the prior information is ignored. Typically an explicit expiry date is included in every document, but is set to be so far off into the future that it is effectively “no expiry”.
(ii) a Days to View expiry. In this case a value of between 1 and 365 days is specified when the secure file is generated using Drumlin. The expiry date is then based on a counter which starts when the file is first authorized. So if the value is 30, the file will expire 30 days after initial authorization, whenever that may be. If the file expires with this option it can be reset simply by re-authorizing the file, and the Dayes to View count starts again, so a further 30 days in the example above.