Keywords

1 Introduction

Digital technologies are embedded in many aspects of people’s daily lives, in their work, entertainment and civic behavior. One result is that people generate and store significant data through their lifetimes [9]. Recently designers have begun to consider issues related to digital legacy [6, 7, 9]. These range from supporting the bereaved [8]; allowing users to plan what is to be done with their own digital legacy [5]; how to curate the digital legacy of a loved one [1, 9]; or even allowing users to create messages to be delivered after their death (e.g. DeadSocial - http://www.deadsocial.org).

One way that people can state their wishes regarding their physical legacy is to draw up a will. Similarly, systems are emerging in the virtual world that let users plan for what happens after their death by creating digital materials, messages or instructions to be sent to loved ones. Some systems use the metaphor of a safe where users can store digital copies of documents, online authentication credentials, and a list of beneficiaries who will have access to them in case of their deaths (e.g. SecureSafe - http://www.securesafe.com/en/product-blog/data-inheritance/). However, such provisions are still relatively rare. In April 2013, Google took a step in this direction with Inactive Account Manager (IAM), a tool that allows users to specify plans for online data associated with a subset of Google products.Footnote 1

To activate IAM, the user specifies parameters to indicate a set of trusted individuals (or beneficiaries), these people’s contact information, and relevant digital assets. This process might seem simple, but beyond the emotional cost of planning for one’s own death, users must also anticipate the future system states that are desired and map these to software configurations; this anticipation includes data accesses and interactions that will be enabled or disabled by these states. Prates et al. [10] discuss the challenges of anticipating what interactions may occur over time from configuration decisions. For digital legacy, having a clear understanding of the impact of these decisions is especially relevant, because users will not be there to repair poor decisions.

In this paper, we present a systematic analysis of Google IAM. Our goal is twofold: discuss the digital legacy management interface; and show how to use Configurable Interaction Anticipation Challenges (CIAC) [10] to analyze support for user configuration over time. Google IAM presents only a few legacy configuration decisions at this point, but our analysis helps to articulate the system design space related to digital legacy management, as well as the more general challenge of supporting configuration processes that impact interaction over time.

2 Methodology

We analyzed Google IAM using the Semiotic Inspection Method (SIM) [3]. SIM is a method of Semiotic Engineering, a semiotic theory of HCI that views human-computer interaction as a special case of computer-mediated human communication involving a system’s designers and users [2]. Through the interface, designers communicate to users their vision of who the system is intended to serve, what problems it can solve or experiences it can offer, and how users can interact with the system. In the case of collaborative systems, the designers’ message includes the roles that members of a group can take, the relationships among roles and members, and the languages and protocols through which users can communicate. Users progressively unfold and grasp the designers’ intended message as they interact with the system and with each other through the system, over time.

SIM can be used to evaluate how well a system conveys to users the designers’ communicative intent and the system’s underlying principles – the system’s communicability [3]. SIM inspects communication looking at how the message is constructed, structured, expressed and delivered (the sender’s side).

SIM analyzes communicability in five steps.Footnote 2 The first three steps deconstruct the designers’ interactive message to users into three segmented views of communication; the final two steps reconstruct the designers’ message with the result of the segmented analysis. Reconstruction involves contrasting the three views from previous steps, which allows the evaluator to spot possible inconsistency among messages and assess the designers’ decisions about which kinds of signs convey what kinds of messages. In the final step the evaluator integrates all results, assessing the quality of the designers’ communication from a message emission perspective.

In our analysis, we focused on how the designers of Google IAM communicate to users about future impacts of their digital legacy specifications. To guide the analysis we used CIAC, a set of concerns raised in an earlier conceptual discussion of issues in communicating how configurable interactions might evolve over time, particularly when the configurations include relationships with other users (see Table 1; the challenges are introduced and discussed in [10]).

Table 1. Configurable interaction anticipation challenges
Full size table

The analysis of Google IAM was performed in March 2015 by an expert in Semiotic Engineering and HCI who has extensive experience in applying SIM. The inspection scenario described a Google user who had just learned about IAM and wanted to explore it to make decisions about her digital legacy assets.

3 Results

We present the results of our analysis in two sub-sections. First we explain the design space defined by IAM (part of the designers’ communication message to users). Second we consider how IAM does or does not address the CIAC (Table 1) over time.

3.1 User’s Decision Space in Google IAM

The Google IAM does not mention “death” or “legacy” in its interface or help; it refers to accounts becoming “inactive” for “any reason” (perhaps because discourse about death is taboo [8]). Nonetheless, in Google’s Public Policy Blog, Google’s product manager announced the IAM as a means to “plan you digital afterlife” (See footnote 1).

Activating the IAM involves four steps: (1) Alert Me: users submit contact information so they can be alerted if their account is about to become inactive; (2) Timeout period: users decide after what period of time without activity their account should be considered inactive; (3) Notify contacts or share data: users nominate people as trusted contacts to be informed and/or have access to (part of) their data once their account becomes inactive; (4) Optionally delete account: users decide whether or not their account should be deleted when it becomes inactive.

The Alert Me step is mandatory. The user’s gmail account is used for this notification. Users must also provide a cell phone number and may add other email accounts. Once the cell phone number is provided, a verification code is sent to the phone and must be typed into the system. Alert Me intends to guarantee that an account will not become inactive without its user’s knowledge.

In the Timeout period step, users may define what amount of time without use is sufficient to deem their account as inactive. Options vary from 3 to 18 months (in intervals of 3 months). In the Notification step, users can name trusted contacts. For each one the user must provide an email address and decide if the contact should have access to parts of their data or just be notified. The user must also write a message for each contact; this message will be sent to that person by Google once the account is deemed inactive. If the user decides to give data access to a trusted contact, s/he must choose which applications’ data should be available and provide a cell phone number. The user is informed that to protect their data from unauthorized access, each trusted contact will receive a verification code over their phone, and that this will be needed in order to access the data. Finally users may write a message that will be sent automatically to anyone who sends them a message after their account becomes inactive.

Lastly, IAM users must decide whether they wish to have their data deleted (after requested actions have been completed). Once all five configuration steps are complete, the user must explicitly enable IAM (clicking on an Enable button). After IAM is enabled users can choose to receive a reminder about it being enabled every 3 months. They may go back at any time and change their settings or disable the IAM.

3.2 Addressing Configurable Interaction Anticipation Challenges

Next we present our analysis of how Google IAM addresses the challenges raised regarding groupware configuration impacts over time.

Anticipation Support.

Users name trusted contacts, write a message to be sent to each, and decide which data can be accessed. The information about how the settings will impact future actions is explained to users through text. The IAM help pageFootnote 3 presents answers to four questions, two of which are meant to help users anticipate the future impact of their decisions, (What will trusted contacts receive?; What happens when your account gets deleted?).

Configuration prompts and help pages explain that trusted contacts will only be notified once the account is considered inactive. The help page explains that Google will add text informing the contact that the user had instructed Google to send the message if the account became inactive (this information is not mentioned on the configuration page). If users decide to share data with a contact, then the configuration page informs that Google will add instructions on how to access data to users’ message. The help page illustrates what the footer to be added to users’ message might look like. Using the word “might” is a signal that the footer text may change between the time the user does the configuration and when the message is sent. Although an example is provided, configuration pages do not refer to it or to the help page in which it is available.

Google recognizes that when a trusted contact receives a (future) message on behalf of the user, s/he may have doubts about it – thus the help system includes one page about the IAM that is aimed at Trusted Contacts.Footnote 4 This page gives an overall view of the IAM, explains the need for the verification code that will be sent by phone to the trusted contact, and notes situations that might make the data inaccessible even to trusted contacts. Interestingly, the email given as an example does not mention the verification code, nor does it mention the help page that explains its role.

Regarding the effects of choosing to delete their account data, users are informed in the configuration page that their data will only be deleted after their requested actions have been completed. In the help page there is a (very) brief explanation about what it means to have one’s data deleted.

Representation.

In the configuration page IAM uses the same interface elements used in other Google products (dropdown lists, switch buttons, etc.). Nonetheless, there are new terms specific to IAM such as “trusted contact” or “timeout period” that are introduced in the configuration interface; for these, IAM offers a contiguous explanation in the interface. The representation of future impacts is accomplished with natural language at the configuration and help pages. In some cases, the information is spread across two pages, and users would need to read both to get a full understanding. Because there are only a few decisions and the explanations are not long, one could argue that reading it would be feasible. However, Google refers to the help page only once in the configuration dialog (within the Delete account step). Thus, the user must take initiative to look for relevant information. IAM does not provide users with means to preview (or experiment with) impacts that will result from their configuration, such as the final form of a notification message to be sent to a trusted contact, which will combine a user-generated message with Google’s explanations.

Costs x Benefits.

Planning the future of one’s data once you are no longer able to manage it is the primary benefit from a digital legacy system [5]. With respect to cost, IAM setup is easy, requiring only four sets of decisions. Also, users need not make all decisions at once and can easily return to change their settings. In relation to the configuration, the existing costs are associated to anticipation, since it is only supported through explicative text spread through more than one page. Also, not all possible future scenarios are addressed in the explanation.

One reason an account may become inactive is due to its owner’s death, which leads to the consideration of a possible emotional cost [6]. The emotional cost may be experienced particularly in writing messages to loved ones to be delivered after one´s death (the message to trusted contacts is not optional). Also, there may be an emotional cost to contacts who receive an unexpected message and gain access to users’ digital assets after their deaths (up to 18 months later), or even worse are informed that the user wanted them to have access to their data, but discover they are unable to do so (e.g. the cell phone number registered in the IAM settings is no longer active).

Conflict Negotiation and Mitigation.

The access to a deceased person’s assets in the physical world can be the source of a number of conflicts. The virtual world per se may solve some of the conflict sources (e.g. each beneficiary may have a copy of the assets, as opposed to dividing it among themselves [9]). The potential conflicts that could arise in the virtual world, are addressed by Google IAM by avoiding them in the users decision space or leaving them outside the scope of the system.

Being named as a beneficiary of another person’s digital legacy may create discomfort if the person does not wish to be responsible for the curation of this legacy [1]. In IAM a nomination does not generate conflict within the system, because trusted contacts are not informed through the system at the time of their nomination, nor are they presented with the opportunity to decline it. Once the trusted contact is informed of the user’s wishes, the user (probably) is no longer available for negotiation.

In IAM, users can only decide to grant access to their digital assets, which means that Google will allow the contact to download a copy of the data. Trusted contacts are not faced with decisions on what to do with the data (at least not within Google). Moreover, they are not informed if there are any other trusted contacts and who they are. If any conflicts take place regarding how trusted contacts choose to use the users’ data, it takes place outside the system, and Google bears no responsibility over it.

The only potential conflict that may take place is between the trusted contact and Google. For example, a trusted contact might receive the message that grants him/her access to a user’s data, but not have access any longer to the cell number registered in IAM; this would prevent access to the data. In this case, Google’s position is supported by IAM rules which inform users of the need of a valid cell number for trusted contacts and how it will be used.

Definition of Default Values.

IAM is associated with a person’s Google account. To activate IAM, users must adjust their account settings (it is off by default). Of the four decisions available to users in IAM, only two have default values – Timeout period (default: 3 months) and Delete account (default: No). In the Alert Me step the user’s gmail is used as the primary email for notification (it cannot be removed). All the other fields within IAM settings have to be provided by the user.

4 Google IAM’s Communicability

Although Google IAM does not directly refer to death, we can see the IAM as a metaphor to drawing up a will; Google plays the role of a lawyer who executes the user’s wishes according to the “law” (Google’s terms and conditions, IAM rules).

IAM allows users to configure actions to be taken in a future time, when they likely will not be available to take actions regarding their data. The CIAC analysis of IAM indicates that Google supports users’ anticipation of impacts their decisions will have in future scenarios by describing them in natural language. Even though the design space presented to users is small in IAM, some aspects about these future scenarios are not explained to users and are not easily explored. For instance, it is not clear why there is a time limit for trusted contacts to download the data even when users have chosen not to delete it. Also, during the configuration process there is no representation of all trusted contacts named thus far along with kinds of access that have been specified, or even whether Google knows about data that has not yet been addressed. Although users can gather this information from the interface, it might be costly (checking as many as 10 contacts and verifying who has access to as many as 10 classes of data). Also, users might have questions about future scenarios, such as What is the data that would be available regarding a specific product? In which format would it be available? Which tools should contacts use to access the information?

Previous literature has shown that allowing users to visualize the future states resulting from their decisions and exploring them (e.g., in a simulated environment) would improve their understanding of the decisions [10]. Building such supports would increase the cost of providing users with services like IAM. Nonetheless, if the design space for user decisions increase (for instance, allowing trusted contacts to make decisions in the user’s name, or defining access to data not by the product it is associated to, but rather by use of finer criteria, such as the tags used to organize it) these tools may not only be desirable, but necessary for decision-making.

Dealing with digital legacy may involve deep emotions for all involved – users who must think about their own deaths and wishes, the bereaved who later receive instructions written by someone they cared about. IAM minimizes dealing with any emotional aspects by omitting references to death, framing it in a broader context. Even simple strategies such as allowing users to preview a message to a trusted contact could help them to gain a better idea of how to frame the request.

IAM avoids most foreseeable potential conflicts that may emerge in digital legacy; currently the decisions about data are based on the user’s settings, Google’s terms and conditions of use, and IAM rules. However the CIAC identified a potential conflict occurring when a trusted contact is asked to curate a digital asset but no longer has access to the data as intended (e.g., a new phone number). The decision to add a security layer for authorizing data access could have an undesirable effect, wherein the users’ digital legacy cannot reach intended beneficiaries. One way to mitigate this would be to allow users to associate a “default” cell phone number to trusted contacts who have Google accounts, thus relying on the trusted others to maintain their own account information. Considering that active users probably maintain that information updated (since it might be needed to regain access to their account in some situations) it would probably decrease the chance of the information becoming outdated. The same strategy could be used in the Alert Me step regarding the user’s own cell phone.

Finally, legal aspects regarding digital legacy are an open issue under discussion in many countries [4]. As countries regulate how data owned by deceased persons should be treated, companies responsible for such data will need to respect such regulations. Still open is which country’s law would prevail – the country of the company, the country in which the data is physically stored, in or the user’s country [4].

5 Final Remarks and Next Steps

In this paper we present the results of a systematic analysis of the Google IAM. Our goal in doing so was twofold – contribute to research related to digital legacy, as well as that of configuration processes that impact interaction over time. Our findings discuss how IAM supports users planning for how to deal with their digital assets, describing the users’ decision space, as well as how IAM deals with some of the issues raised in recent literature on digital legacy. The findings can be useful to researchers working on proposing requirements for such systems, and professionals involved in (re)designing digital legacy planning systems.

The research regarding anticipating impacts of configuration settings in collaborative systems over time covers a broader scope of domains. Nonetheless, digital legacy planning is an excellent domain for consideration, because all impacts will take place in a future in which users will not be around to check if their configuration decisions achieved their intended effects. By using the interaction anticipation challenges proposed in [10] we have generated a specific account of how these challenges can be useful to the designing or evaluating digital legacy systems. Also, the analysis illustrates how to use CIAC in combination with SIM.

In our work, by using SIM we analyzed designers’ decisions; an interesting future work would be to contrast this analysis with one taking to a user’s perspective. Future directions for digital legacy could involve analyzing other systems that help users to plan for their digital assets, and compare this to the decision space offered by Google. Moreover, it would be interesting to compare what we learned by analyzing IAM with the help of CIAC and SIM, with what can be gleaned from other analytical tools.