The new data transmission permissions seem to be misleading to users

Add-ons addons.mozilla.org
1

I’m the developer or SponsorBlock, an add-on for skipping integrated sponsorships, intros, outros and other unwanted sections of YouTube videos. It is a crowdsourced add-on, and relies on submissions on each individual YouTube video. Because of this, it fetches data from the server asking what submissions exist for a video, and uses that to skip parts of it.

But privacy is integral, and we take many steps to make that the case. The add-on does not send what video you are watching to the server, instead it uses a K-Anonymity system (you can learn more about that here) that makes it so the server doesn’t know what you are fetching, but not every video’s data has to be stored on the client. The add-on uses randomly generated local users for submissions instead of a social media login, or email to ensure we have no personal data we could collect, because we don’t want that.

But these new data transmission permissions seem to require us to declare many things anyway which are going to make users very confused. Even though the video you watch isn’t transmitted, it does imply you are on the youtube.com domain, which means the browsingActivity transmission type is probably required. It may even require the websiteContent because of the fact that it also sends some requests for the related videos that appear on the page, even though these are again using a k-anonymity system. Maybe that’s not needed since the domain sent isn’t really extra information, I’m not sure.

If SponsorBlock is required to add websiteContent to the declaration, it is now placed in the same category as cookie stealers, scam extensions like Honey and others. Even though it transmits nothing close to that, and for sure stores absolutely none of it.

Right now I see several big issues for implementing the data transmission declaration in the SponsorBlock extension:

  1. The upgrade flow for existing extensions is scary: If an existing extension adds a mandatory transmission type, it appears as “New required data collection”. Extension users are rightfully accustomed to new permissions meaning that an extension was acquired or hacked and are rightfully skeptical when they see this notice, and will treat anything written there with the most nefarious interpretation as possible. This isn’t a theoretical problem, we’ve already seen hate mobs and conspiracies created all over social media due to an existing extension who have added declarations in an update. There is no way to provide any explanation to the user.
  2. No distinction between transmission and collection: The UI shows “data collection” when the declaration is not about that. The declaration is not about storing data, only about transmitting it. An extension which uploads all your personal information and stores it for eternity looks exactly the same as an extension who does unlogged requests which partially reveals a website you visited.
  3. Not clear that data collection is only happening on domains the extension has permission for: The current collection prompt implies that the extension is collecting all of your browsing activity when it doesn’t even have access to that
  4. No distinction between hidden elements (cookies, request headers) and user visible elements: There is a big difference between transmitting data that reveals visible page contents, and secretly sending your cookies to a server. The current model does not differentiate

My recommendations:

  1. Better upgrade flow for existing extensions: Provide a way for extensions to explain to users what is happening. Ideally, Firefox should say that this is a new requirement being introduced, and not a change in permission. A customizable “Learn more” button would help here
  2. Splitting off collection and transmission: There is a big difference between the following phrases: “The developer says the extension will collect browsing activity”, “The developer says the extension will transmit browsing activity”, “The developer says the extension may transmit browsing activity”
  3. Allow an explanation to be included with mandatory permissions so that extensions with privacy preserving features can inform installers how they are safe
  4. Include the domains the extension has permission for somewhere in the prompt to inform the user that collection and transmission will only happen on those sites
2

Return Youtube Dislike’s developer here. Extension that keeps dislike counts “in parallel” to YouTube’s official like and dislike count.

Situation is similar to Ajay’s - all we receive from the users are randomly generated usr IDs and videoIds. We didn’t go as far as K-Anonymity implementation, but still, I consider the extension to require close to bare minimum information.

Yet the message my users receive after I’ve filled the disclosure according to guidelines is on the screenshot. The reaction is abysmal, calling my reviews section a shitstorm is an understatement. People are sure that I’m stealing all their data from all websites (despite extension only having access to YouTube).

https://addons.mozilla.org/en-US/firefox/addon/return-youtube-dislikes/reviews/

image
image505×282 11.9 KB

3

not a developer, but a user of RYD. I can agree that these new data transmission permissions are very misleading. Just commenting to get more eyes on this

4

I disabled RYD thinking it had been acquired by some marketing company and was now recording my activity.

The wording of the new permissions dialog is VERY misleading.

5

Not a developer, but also a user of RYD. Mozilla’s new wording is causing more problems than its solving.

Why Mozilla decided to make the wording of the new permissions this way is beyond me.

6

Hi there, this is Christos from the Add-ons team.

We appreciate and welcome feedback from developers/users.

These data collection disclosures aren’t new, and seeing one in an update doesn’t automatically mean an extension changed what it does. Here is how we got here:

Even though we haven’t retroactively asked all the published Add-ons to comply with this policy, we do it every time they submit a new version/update.

We want developers and users like you all in every step of the process, especially when we are considering a change. We really value your feedback, and we are committed to building a safe ecosystem for everyone.

I can’t promise anything specific right now, especially one year after the release of the permissions. But what I can do is bring this thread, with your points as you wrote them, to the team,

Three points in particular stand out as fair:

  • the upgrade flow for existing extensions
  • the difference between transmitting and collecting data
  • the prompt not showing which sites the extension can actually access

Once we’ve discussed those points, I will share updates here.

Thank you

-Christos

7

I’m another RYD user that was freaked out by the new permissions. They are way too general, the old ones were much more specific. Here is what’s missing from the new permissions guys

image
image463×204 50.3 KB

8

Also if I could leave a note why each permission is requested.

Identifying information: random ID to count your votes, not tied to other PII.
Etc…

9

I’m overall in favor of this update since it does require more transparency on the part of the extension maintainers/creators, but I do think that it is much too broad to just state that PII is collected and not have an explanation/usecase/timeline/etc field.

It seems like you got the major issues here, so hopefully you can provide developers more options to clearly communicate to the end user :slight_smile:

10

I use netmirror extension i found a issue so delete browser and download the browser and trying to add the extension it shows the host removed the extension so what should I do?

11

Honestly, it looks like a sabotage. Extremely broad, unspecified permissions can only lead to one of two outcomes - paranoidal refusal to use extensions at all, or treating them like ToS - accepting without reading.