xDECAF 😆☕

Appearance

📊 Diagram: (Smart Speaker Platform from Precise Analysis of Purpose Limitation in Data Flow Diagrams) ​

Available Online

This model is available to view using the online editor!

Open In Online Editor (No Violation)Open In Online Editor (Permission Violation)Open In Online Editor (Storage Violation)

View Full Main SourceOpen Example Model in Example Models Bundle

Repository

📝 Short Description ​

This diagram shows a fictional Smart Speaker system. The use cases include the download and install process as well as voice-guided command sequences and data exchanges with third parties.

🔤 Abbreviations ​

  • CMD: Command

📖 Extensive Description ​

The Device Owner can first download the mobile app for using the smart Speaker. After the initial setup, the user will login to the app and connect the Speaker to the local network (the Router). The user can also log in to the Music Store. The user activates the speakers’ microphone and sends voice_requests which are processes by the Provider, returning the corresponding command back to the Speaker. The Speaker then invokes the Music Store API provided capabilities to stream the desired content. Finally, the Provider may send certain aggregated statistics about their history of clienteles’ requests to Third-party Partners.

🏷️ Label description ​

-### 🗂️ Data Labels:

  • Purpose: These labels mark the intended purpose of a given data flow between two nodes. These can be: Install, Login, Authenticate, Register, Streaming, NotifyUser, CMDProcessing, VoiceProcessing, TriggerMusicStore, Marketing, Storage, AIProcessing and NoPermission.

🏷️ Node Labels: ​

  • AllowedPurpose: These labels designate allowed purposes to nodes. They are a subset of Purpose labels: NotifyUser, Streaming, Register, Marketing and Storage.
  • ComponentCategory: This labels the nodes according to their place in the overall system. There are: UserHomeDevice, MusicStore, UserPhone, Provider, DeviceOwner, Router, ThirdPartyPartner and AppStore.

⚠️ Constraints ​

StorageConstraint ​

This constraint ensures that data flows marked for Storage Purposes are never handed to an entity from the ComponentCategory UserHomeDevice.

  • StorageConstraint: data Purpose.Storage neverFlows vertex ComponentCategory.ThirdPartyPartner

PermissionConstraint ​

This constraint ensures that data without permissions is not processed within the UserHomeDevice.

  • PermissionConstraint: data Purpose.NoPermission neverFlows vertex ComponentCategory.UserHomeDevice

🚨 Violations ​

Although no violations were found in the original architecture, we have slightly modified the diagram to produce two alternate versions in which violations are introduced:

  • In the first diagram, as the new user has not given their permission for their voice data to be used within the system, the PermissionConstraint is violated.

  • In the second diagram, user data marked for storage flows to a Third-Party Partner, which violates the StorageConstraint.