![[Dazzle Logo]](/assets/dazzle-4412x5541.png)
To be as specific and actionable as possible for product teams, we have created the following user stories that we believe need to be implemented by covered SMSs to meet the specific requirements and intent of the law. We annotate them with our reasoning why we believe they are required.
In later sections we surface some key strategic decisions SMSs need to make, and outline some approaches for how to implement these user stories including the primary challenges in doing so.
Data portability features
Assume a user A is using an SMSA. User A can easily obtain a complete set of all their personal data held by SMSA. The obtained data set is readily usable to be imported somewhere else. For example, if another SMSB were to implement an import interface, the user can import the exported data there, and there are no limitations in the exported data set that prevents SMSB from reconstituting all aspects of the exported social graph and re-connect them with other data elements already imported by others into SMSB.
Source: 13-61-201(3), 13-75-201.
The law requires social media operators to implement the export in a “usable format”, but it does not require them to implement import Reportedly, no import is mandated in the law because the US Supreme Court ruled that social media companies have the right to refuse hosting content. However, lawmakers are expecting that companies will implement it anyway, because it lowers the barrier for users currently using a competing SMS to move to theirs. , so there is no user story to describe this.
Social media interoperability features
If a SMSB (voluntarily) implemented this functionality, a user B using SMSB can follow and interact with the content posted on SMSA by user A after users A and B have given the required permissions, even if A and B are using different SMSs. SMSA is required to provide the open interfaces so that any SMSB can implement this.
Source: 13-75-202(1)(b)
There is no requirement on SMSs (e.g. SMSB) to enable their users to follow and interact with users and their content that use other SMSs (e.g. SMSA), only that other SMSs (SMSB) can implement that feature if they decided to. SMSA cannot prevent that if the user agrees Similar to the discussion about requiring export but not import above, there is no requirement that a social media service listens to reactions elsewhere to content originally posted to their service if those reactions are made on a second social media service. It is hoped that they will implement that anyway for competitive reasons, as otherwise the majority of a conversation started on their SMS may take place outside of their own SMS and that may not be desirable for them. .
Assume that initially, users A and B are both users of SMSA and connected there. After B has exported their personal data from SMSA and imported into into SMSB, and after users A and B have provided the necessary permissions, user B can ontinue to see content posted by A on SMSA, but now from their account on SMSB.
This is not explicitly stated, but a consequence of the required data portability features, the required interoperability features, and the explicit intent to counteract “companies … preventing users from easily sharing posts and interactions across different platforms” (13-74-102(2)).
User consent is required before any of their data is shared with another SMS.
Source: 13-75-202(5)
Personal data synchronization features
A user can easily identify a set of other social media services and other 3rd parties with which they want to share personal data synchronously.
Source: 13-75-202(1)(a)
The term “synchronously” is likely to be interpreted in the same way as the phrase “continuous and real-time” in EU legislation.
A user can designate which of their personal data will be shared synchronously with the identified other social media services, and not with others.
Source: 13-75-202(1)(a)
The law does not state that this is intended to be limited to unidirectional sharing. So if a user A were to share the profile they created about themselves on SMSA with SMSB, and then SMSB were to use that shared profile for the user’s account on SMSA as well (which would make sense: maintain only a single profile for several services would make life easier for users in many casesThe same use case as addressed by Gravatar, although it addresses is in a centralized fashion and not through “synchronization” as required here. , and then the user made a change to the profile on SMSB, the change would need to be synchronized back to SMSA.
Source: “…multiple social media services can access, contribute to, and synchronize a user’s personal data” (13-75-101(1))
A third party, with the permission of the user, can obtain real-time notifications when their personal data is newly available for sharing or when previously shared personal data was updated.
Source: 13-75-202(1)(b)
The language is very broad, and applies to the synchronization of any kind of personal data the social media service has received from a user. Any kind of receiver approved by the user must be able to receive these notifications, not just SMSs.
Other required features
The bill also requires social media companies to allow users:
-
to check whether the company holds or processes their personal data (source: 13-61-201(1)(a));
-
to delete their data (source: 13-61-201(2));
-
to opt out of targeted advertising (source: 13-61-201(5)(a);
-
to opt out of the sale of their personal data (source: 13-61-201(5)(b);
-
to correct inaccuracies in their personal data (source: 13-61-201(4)).
These features are approximately the same as those already required by other data rights legislation, such as the CCPA/CPRA in California. As these features are already well known and broadly implemented, we will not discuss them further in this paper.
Qualitative requirements
The above features need to be implemented:
-
Using open file formats, standards and protocols (source: 13-61-201(3), 13-75-101(1), 13-75-201, 13-75-202(3)). That means:
-
Must be free from licensing fees.
-
Must be free from patent restrictions.
-
Must be well documented.
-
There is no requirement that a particular set of protocols or standards is used.
-
There is also no requirement that all SMSs subject to the law must implement the same protocols.
- However, the regulator can identify open protocols that, when implemented by an SMS, create the presumption that the implementation meets the law. So far, however, the regulator in Utah has not done so and is not expected to do so in the immediate future.
-
-
In a manner that safeguards privacy and security (source: 13-75-202(3)(e)).
-
Their use must be free up to a certain “reasonable and proportionate thresholds”, which cannot discriminate between SMSs (source: 13-75-202(3)(a)).
-
The entire social graph (covering user accounts, their relationships, and content items and reactions and their relationships to other content items and user accounts) needs to be preserved during data export or for interoperability purposes, as the intent is that the user can change from one SMS to a different SMS without loss of data, or connections.
-
Data created by other people and marked as private is excluded from the exported or shared social graph (source: 13-75-101(3)(c)).