privacy-tech-lab / gpc-privacy-choice Goto Github PK

Research version of optmeowt-browser-extension

NOTE: This version of the extension will not be used for production and is not to be combined with the current extension. The official browser extension will not collect any user data! This research version of the extension is used purely for research purposes.

TO DO:

• implement popup with a prompt introducing GPC; provide users with options to of turning on GPC settings for selected websites or for all websites (global)
• implement functions on the extension to collect data on how users will interact with the browser extension, i.e. whether the global setting is turned on or only applying GPC to certain pages
• implement other functions on the extension which collect data on other areas of the research interest [to be confirmed]
• connect the extension with the backend server to store the research data for analysis

The current implementation has an issue:

User is created upon installation of the browser extension, since this takes a short amount of time to finish, if the user immediately visits a website after installing the extension, a new piece of browsing history is generated before the user is created in the db. Since firebase tries to add the user into the db without having a user created, we end up having an empty user created which tracks the initial piece of browsing entry.

As shown above, the first user and the second user are the same user but the first entry is added since firestore had trouble finding the current user (not yet created) to store the browsing history. This issue will attempt to solve this problem

• clean up the options component of the extension

This issue serves as a documentation of the proper behaviors of our extension. Let's keep track of a list of descriptions on the PROPER BEHAVIORS OF OUR EXTENSION, feel free to edit this comment, but when in doubt, let's always refer back to this issue for what the extension should do:

• 1. User clicks APPLY ALL from the banner** ✅ The setting chosen from the banner is applied to all (past and future) of the domains

• 2. Users clicks APPLY TO ALL settings, then TURN OFF UNIFORM SETTINGS** ✅ Original setting in the domain list remains unchanged; But the uniform setting is turned off, therefore, new domains will have banner pop up

....[To Be Continued]

The way the settings page and domain list logic is currently set up is pretty confusing. If the 'Apply All' checkbox is checked in either case – that is, no matter 'Allow' or 'Don't Allow' – the domain list, from that point on, will no longer be updated, even when new domains are visited. This restricts user choice by preventing them from individually changing preferences if they decide at a later date they no longer want to 'Apply All.' Furthermore, if the 'Apply All' box is checked and the user chooses the 'Don't Allow' button, the domain list does not reflect that the GPC signal is being sent. That is, the switch is toggled to 'off' for the present domains. We should discuss this when we can and clear up any confusion.

• clean up the pop up component of the extension

Looks like Firebase would be a good choice. @ekuller and @chunyuema will look a bit more into it. A no-SQL database is fine as we do not need to query any data. We just need to collect the data and once the data collection is finished need to get it out for our data analysis and further processing in R, Python, etc.

Originally posted by @SebastianZimmeck in #54 (comment)

Currently the domain of the current site that is being referenced to get the GPC value is not just the top level domain, which means it is mismatched from the domains in the domain list.

There is a variation of scheme C that @chunyuema and I had discussed as one of our initial schemes on Friday. In this variation the popup notifying the user of their choice and possibly allowing them to change it would be displayed when a user clicks on the pinned research browser extension icon (similar to how the popup that appears in optMeowt). We could possibly implement this as a 4th scheme or add it as a feature to the other schemes.

from comment in #40

Though, one other consideration in this context is that if we err on the side of making it slightly more difficult for the user to opt out of all, we are a little bit less exposed to the argument of substituting our choice for the user's choice and thus their choice should not count.

@SebastianZimmeck that makes sense. Because we will also have to change the message in the banner, I'll open a new issue where, at a later time, we can address more specifics of the UI, in terms of what gives the user the most free choice. For now because the functioning foundations of the front end have been set I'm going to close this issue and squash and merge the corresponding pull request.

Originally posted by @ekuller in #21 (comment)

This is ideally the last bit of clean up we need to do before moving on, items to be looked at include the following:

• contentScript.js
• cookie_lists_json.js
• dom.js
• domainList.js
• usprivacy.js

Most of the functionalities should not be relevant to our project so I am expecting a lot of deletion.

Filter out 1st party requests using top level host domain (use API/method that @chunyuema used in issue #60).

Let's have this issue be dedicated to the styling of our banner. Let's try to take care of:

• Moving the "Apply All" button and taking away the semi-colon following it
• Generally making the banner look less like a website component and more like a browser component
• Additional miscellaneous fixes

We also need to have a mechanism that shows the banner on the website or omits it.

The simplest case is if a user selects that GPC signals should be sent to all sites. In that case the banner is not shown anymore.

Another case is if the user goes site-by-site. In that case we would need to check whether a site is in the domain list (and what its setting is). If the site is not in the domain list, the banner should be shown. If it is in the domain list, showing the banner depends on what the selection is in the domain list.

The bottom line is that there needs to be a check against the domain list.

This is not fully thought out, but I wanted to flag this issue as it just occurred to me.

(assigning all three of you, @bella-tassone, @chunyuema, and @ekuller; we can decide later on who does it; or if any of you wants, feel free to pick up this issue)

I will look into whether it's possible for our data collection to include the choices a user makes through what they click on.
This could include, but is not limited to:

• What button(s) they press when presented the privacy pop-up
• If/when they click on ads presented by first-party websites

For some reason, testing the current code results in a bunch of numbers being added to the domain list, as shown below.

It seems that, the more domains visited, the more numbers appear on the domain list.

The icon of our extension is set properly to either red or green based on the GPC signal status. However, in certain cases, we get errors and the reset of icon images fails.

Case1:

Case2:

I opened this issue now just to track it so that we can come back later. We will move on with other features and troubleshoot this bug later.

The readme is not reflective of the code at all. Most (all?) text can go out.

As we discussed today, a user may opt out from the tracking on all sites and, thus, may not know where to change their opt out settings. It may help to have one small notification upon installing the extension pointing to the pop up icon (which leads to the settings/domain list) that that is the place where they can make changes to their opt out settings.

Currently, our privacy banner does not actually do anything. That is, both the 'Allow' and 'Don't Allow' buttons simply close the banner. We want to implement the functionality of these buttons. More importantly, we should be logging how users interact with the banner (which buttons they press). Secondly, if convenient we should have a GPC signal be sent if the Allow button is pressed (where it is sent would depend on the status of the 'Apply All' tab). If possible, we want the browser extension to function as we describe it, even though it is only being used solely for research purposes.

There are currently instances in which our banner functions unreliably (that is, it doesn't appear as it should). Let's work on this, and furthermore check the overall reliability of our banner later on by testing it on different websites. We should be able to confirm that it works properly on most, if not all sites.

I think we should add a sub collection to Browser History entries that will hold documents for relevant third party requests made on that site.

For some reason, it is no longer possible to disable sending the GPC signal to a particular domain from the pop up section. When trying to turn it off from the button on the pop up page, it is not reflected in the local storage, meaning GPC signals will still be sent when requests are made to the same domain.

GPC signal can be enabled for a single domain from the pop up page. In addition, it could be enabled/disabled from the options page as well.

This problem exists for issue2 as well, which means we have introduced the bug at some point last week. Since it is on the pop up section, I am assuming that this is from my part, even though I don't remember breaking this feature. I will investigate this issue first before moving on to clean up the rest of the features.

• improve the consistency of the checkbox on the banner across different sites

• remove the toggle functionality in the settings page
• only keep the domain list
• potential implement apply all functionality in the domain list setting page

While attempting to make some small changes to the Setting Interaction History collection in our database, I uncovered a larger problem. The current implementation does not account for changes such as turning off the universal setting, or deleting domains. Furthermore, it is difficult to account for such changes because the standing design only focuses on whether the GPC signal is sent to existing domains or not. Simply put, it is hard to eloquently record all possible interactions with the current set-up. As such, I will be reworking the design in order to better account for all possibilities.

• remove unnecessary functionalities from the optmeowt-browser-extension
• possibly do some refactoring during the process to make future development easy
• [optional] maybe upgrade the manifest to version 3
• [optional] possibly looking into other technologies for frontend: react

As discussed with @chunyuema and @bella-tassone, there may be still a number of code, assets, ... that is not needed once @chunyuema merges the issue-2 branch (issue #2). I will go through everything at that point to identify those.

• change the domain parsing mechanism to only track the top level domain

There is a variation of scheme C that @chunyuema and I had discussed as one of our initial schemes on Friday. In this variation the popup notifying the user of their choice and possibly allowing them to change it would be displayed when a user clicks on the pinned research browser extension icon (similar to how the popup that appears in optMeowt). We could possibly implement this as a 4th scheme or add it as a feature to the other schemes.

from comment in #40

We want to add (to the research browser extension) a banner that obtains users' preferences on being tracked. Although later on we may want to specify when/how often the banner pops up, as well as the functionality of the buttons, considering our purpose, that isn't the most important aspect of the banner, and we can come back to those ideas later. For now, let's focus on simply creating the banner.

One interesting point to analyze may also be to correlate a study participant's interaction with ads and their banner settings. For example, do people who are applying do not track me to all sites never click on ads? If so, advertisers would actually not incur much of a loss if opt out options are displayed more prominently because those users opting out would not interact with ads anyways. Thus, it would be good to know if we would have that information, i.e., not only keeping track of the third party HTTP requests, but also whether a user actively triggered those by clicking on an ad.

At the moment, I am not exactly sure how to implement such functionality. Maybe, there are JavaScript listeners on clicking an element on a site that can help us here.

Possibly, this information can become part of the browser history.

For the time being, I assigned all of you, @bella-tassone, @chunyuema, and @ekuller. But feel free to re-assign/un-assign as you see fit.

Bella will update the README to better reflect the current status of our project, as well as to document different aspects of how we will be collecting our research.

• problem: after selecting the apply all button, domain list no longer tracks the new domains

We need to implement the tour of the extension that will be present in one of the schemes (let's call it scheme A). The tour should inform the user how to change the ad tracking settings of individual domains in the domainlist.

Originally posted by @ekuller in #40 (comment)

• Extension experiences a delay in updating the whether the GPC header signal is sent, this issue will address that issue

Currently, the source files have outdated info, i.e.,

OptMeowt is licensed under the MIT License
Copyright (c) 2020 Kuba Alicki, Daniel Knopf, Abdallah Salia, Sebastian Zimmeck

It should be updated to:

OptMeowt-Research is licensed under the MIT License
Copyright (c) 2021 <you guys in whatever order you want to appear>, Sebastian Zimmeck

We need to create a GIF that will display how to change the ad tracking settings of individual domains in the domainlist, and show the GIF to users when appropriate (scheme B). (QUESTION: will we attatch the GIF to all of our original popup banners or just show it to users when they select an "apply-all" setting?)

Originally posted by @ekuller in #40 (comment)

We need to implement scheme C, in which once the user selects an apply-all setting, a small popup will appear for a few seconds in the upper right corner of new domains visited that will remind them of and possibly allow them to change their choice for that domain. This scheme maximizes active choice, but has questionable usability.

There is a variation of scheme C that @chunyuema and I had discussed as one of our initial schemes on Friday. In this variation the popup notifying the user of their choice and possibly allowing them to change it would be displayed when a user clicks on the pinned research browser extension icon (similar to how the popup that appears in optMeowt). We could possibly implement this as a 4th scheme or add it as a feature to the other schemes.

Originally posted by @ekuller in #40 (comment)

There is a logical error that occurs when there is a global GPC setting, but unique settings for some individual domains. In this case the GPC signal is sent to domains even if the global setting is to allow tracking and selling. To fix this error I need to add applyAll to cache so it can be read synchronously in updateSendSignalandDomain(). Then, I can fix the logic with the following code

if(domainlistEnabledCache){
    if (!(domainsCache[currentHostname]===undefined)) sendSignal=domainsCache[currentHostname]
    else{
      if (applyAllCache) sendSignal=enabledCache
      else sendSignal=false
    }
  }else sendSignal=enabledCache

enabledCache holds the global GPC setting.

We want the different situations that @chunyuema has implemented in his logic to occur based on how users interact with the banner. That, is, different things should happen depending on whether the user clicks the 'allow' vs. 'don't allow' buttons, and whether they have the checkbox 'checked' or not. This issue is very closely related to #23, but let's use it to try and hook up the back-end logic to the front-end banner.

In case the DOM injection affects too many pages, there are other possibilities as well (possibly to explore in a separate issue).

Originally posted by @SebastianZimmeck in #21 (comment)

On the most basic level, there are two extremes: an opt out scheme could be asking the user at every website they visit to opt out from that site's tracking or they could be asked to opt out from all websites's tracking at once. The first is not usable and the second is too broad. So, we need to come up with a scheme in between, i.e., that is usable and that at the same time allows per-site decisions.

@ekuller brought this issue to the forefront with a particular use case: a user may only want to opt out from the tracking of one particular site (maybe because they perceive the site as particular invasive) but otherwise is fine with being tracked on all other sites. In that case it seems that, according to our current design (and implementation) of the domain list, the user will be forced to endure the choice banner on all sites they visit. That seems unusuable.

This issue is purely about the design of an opt out scheme (and as such may play into issue #23). However, there is also an implementation dimension, which we may want to address in a separate issue, but which we may also want to take into consideration for the design here. As the opt out scheme is currently implemented, if a user opts out from sites individually, the domain list determines whether the choice banner will be shown for a particular site. On the other hand, if a user opts out from all sites, the banner will never be shown. Applied to @ekuller's case, the banner will be shown according to the domain list for all sites except the one that the user opted out from.

To get the thinking started on refining our design (I do not think we need to start from scratch completely), one idea could be to use something like apply to all sites for which you have not made a specific decision yet instead of apply to all sites. I have not full thought this through, but maybe there is something we could do with that ...

I think we are approaching the last stage of our development in terms of all the core functionalities of the project, and it is nice to see that we are making good progress. As for now, we need to work on the data collection a bit more, and then add in logic for handling and displaying different schemes of the users. After that, I believe we can started testing it internally to make sure that our extension gathers all the data properly. However, it has been increasingly clear to me over the past few issues that our code might need some refactoring to stay clean. Specifically, I observed the following issues:

• At different places, we are not following the DRY principle and performing same tasks with repeated codes
• Due to the manifest version, we are having multiple callback functions nested in one another
• At certain places, the code could potentially be better organized

However, I would like to point out that the code base is still rather clear and the functions seem to be working fine as well. There fore, refactoring is likely not going to be very necessary for us. And I am going to label this as low priority. It is nonetheless a good thing to do if we have time either before working on the schemes or after completing that. We can discuss more on this.

• clean up the background section of the extension

Once we have stripped down our extension of all unnecessary functionality, we will implement the data collection functionality. For example, when a study participant visits a website, we would like to send the URL, date, and time to our server. In essence, our extension needs to send data to our server.

A few years ago I implemented browser extensions, apps, and a server for a very similar purpose. The code is here. It may be possible to reuse some of the code or at least get a sense of how it can be done. Though, it may be also easier to start from scratch.

This issue likely has to be broken down in multiple smaller issues. I am mostly posting it as a reference.