Week 17: Preparing towards the D-day
May 3 — May 7, 2020
This week started off with us undertaking 4 tasks:
- Refining our concept for all used cases.
- Establishing a storyline for the product video.
- Development of refined UI wireframes according to the video storyline.
- Creating a structure for our final upcoming presentation.
- Concept refinement
Setting the premise
- We realize that in order to help the user gain autonomy over digital data, it is important to actively include them in the process of data collection.
- Privacy agreements currently, present a highly unbalanced model with service companies dictating the terms of use which the user has to agree to in order to avail the service.
- We realize the need for a fair model where informed users are given an opportunity to discuss and demand the terms of use for the service companies to agree to without it being a cognitive burden.
- With the European Union implementing laws like the GDPR, we understand the need for intervention at a systemic level as well to support the product level intervention for it to function sustainably.
The proposal
We propose a future scenario where-
- At a systemic level, 3 entities are involved in successful data transactions:
- Data Makers- who are the data generators, and the users of different services or apps.
- Data Takers- who are the service providers, who collect this data generated by the data makers
- A third entity- in the form of a regulatory body residing at a higher level of influence might be government-specific: for example- the European parliament creating the GDPR, or a similar common universal entity with an identified ‘set of rules’ with a higher authority. The body consists of field experts and policymakers.
- This body is created to uphold the interests of the data makers by regulating the relationship between makers and takers through a ‘set of rules’.
- These rules will provide transparency for both these stakeholder groups to maintain a fair relationship.
- Now, to understand these sets of rules, let us first understand the categorization of user data that we propose.
- Data that a user generates is divided into 8 categories or data points- Demographics, Location, Transactions, Browser and cookie tracking, Health, Communication, Accounts and connected devices, and Interests.
- Data is further divided into 3 tiers based on its essentiality for a service. The 8 data points that we saw earlier will lie under each of these tiers. This set will be different for different companies. Now, the question is, who decides which data points fall under which tier for a particular service. Right? I mean for example, who decides for Uber that location data falls under tier 1, and Demographics may be in tier 2. Because definitely, the service companies in order to get more and more data from the user data will argue that all the 8 data points are integral for service functioning and should lie in tier 1.
To answer this, let us look at the relationship between the data takers and the policy regulators.
Data takers- Policy regulators
A data taker (which is essentially a service company) submits a proposal with the requirement of specific data points in the 3 tiers. The regulatory body amends over this proposal through a series of negotiations with the data takers. It inspects the validity or the appropriateness of each data point belonging to a particular tier. If the validity of a data point belonging to a particular tier is not justified, the data point is bumped down in tier.
Thus, the data takers have an amended set of data points belonging to particular tiers.
Now, let us now look at the relationship between the Data Makers and Data Takers.
Data takers- Data makers
- At a product level, through our intervention, the data makers also develop a preferred set of data points belonging to particular tiers. Thus, there are two sets of preferences developed from both the ends- data takers and data makers.
- A match between these preferred sets of preferences provides transparency and facilitates a fair transaction between data takers and data makers. In case of a mismatch, a data takers request access to a particular data point belonging to a particular tier. Data makers can thus make an informed choice whether to permit or deny access.
UI for product features at:
xd.adobe.com/view/a67fba14-b919-487e-53b0-e002065bf29d-d04e/
Concept video iPrivacy:
Some reflections/questions from the final presentation
- Business model/ policy adoption
The intervention heavily depends upon a policy framework at a legislative level. Although the path to adoption seems arduous in the present times, we are witnessing an inclination towards policy regulation pertaining to data use globally. We are determined to ride on this wave and hope for the adoption of iPrivacy in the United States as a mandate. We understand that compliance with iPrivacy might seem like a burden for service companies.
However, iPrivacy is also an opportunity to reimagine business models for a data-driven age. The principle of ‘privay by design’ is a challenge for businesses to leave behind models that rely on blanket collection of data in search of more new, targeted approaches. The rewards are tempting: reduced reputational risk, lower operational costs, and greater protection from cybercrime.
2. Adoption through every operating system
We highlight that the intervention resides in the iOS eco-system. Our product level intervention to support the smooth functioning of this system is placed within the Apple ecosystem. We propose this product as an integral part of the operating system to prevent any third party influence, which is common with apps that are developed outside the OS. iOS is our platform of choice for two reasons:
— Apple deems user privacy as essential, and for many years, it has endeavored to provide transparency pertaining to data collection, distribution and use.
— Its app store has a strong team vetting incoming service applications on the basis of their privacy requirement.
However, in the event of the framework being adopted as a legislative policy, in our preferred future, we envision a similar product to be a part of every Operating System’s mandate.
Final presentation May 7, 2020 at:
Back-end workflow at:
