Opened 3 years ago

Last modified 3 years ago

#4872 closed change

Update privacy policy with information about Adblock Browser error reporting — at Version 23

Reported by: mario Assignee: juliandoucette
Priority: P2 Milestone:
Module: Websites Keywords: goodfirstbug
Cc: saroyanm, juliandoucette, shikitita, jnink, jeen, lisabielik, wspee Blocked By:
Blocking: Platform: Unknown / Cross platform
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):

https://codereview.adblockplus.org/29424653/

Description (last modified by mario)

Background

With #4672 we introduce opt-in "error reporting" to Adblock Browser for iOS, which will be released on the 28th of February 2017. This new feature requires us to update the privacy policy

What to change

On https://adblockplus.org/en/privacy#abb_ios change the Adblock Browser for iOS section contents to:

## Adblock Browser for iOS

### Crash and error reporter

In the event of an unexpected crash or error, Adblock Browser for iOS collects data relevant for analyzing the cause of the malfunction and transmits it to our ​HockeyApp account. The data is solely used for individual troubleshooting (as well as for identifying general defects which lead to unexpected crashes or errors) and is never shared with any third parties other than HockeyApp.

During a crash, the following data is sent:

- Bundle identifier, bundle version and short bundle version string of Adblock Browser for iOS.
- Device type, CPU architecture and version of the operating system.
- Timestamp of when the crash happened.
- A generated UUID to prevent duplicate crash reports.
- If an exception was thrown, the plain-text class name and message value of the exception.
- Low level crash data like instruction pointer, method or function names, signal data, pointer registers and information about the loaded binary images.

During an error, the following data is sent:

- Bundle identifier, bundle version and short bundle version string of Adblock Browser for iOS.
- Device type, CPU architecture and version of the operating system.
- Timestamp of when the error happened.
- A generated UUID to separate error reports.
- A string/function name identifying the error.

Said data is only collected when the application crashes or throws an error. Furthermore, Adblock Browser for iOS explicitly asks for permission to send the collected information after the crash or error happened. All reports stored on our servers are removed after 30 days.

In order to learn more about HockeyApps's privacy policy, please consult their ​[Terms of Service](http://hockeyapp.net/terms) as well as their ​[crash report documentation](http://support.hockeyapp.net/kb/app-management-2/what-data-is-collected-with-crash-reports) and [event report documentation](https://support.hockeyapp.net/kb/app-management-2/what-data-is-collected-with-the-hockeysdks-2#data-collected-for-the-user-metrics-features).

Additional information

  • For better readability, you'll find a RTF document with the changed passages in red here.
  • Changes are already approved by Legal.
  • Translations will be provided via CrowdIn by 2017-02-24
  • ABB 1.5.2 will be released by 2017-03-10. By then the changes outlined above are supposed to be published.

Change History (24)

Changed 3 years ago by mario

comment:1 Changed 3 years ago by mario

  • Description modified (diff)

comment:2 Changed 3 years ago by mario

  • Description modified (diff)

comment:3 Changed 3 years ago by mario

The deadline of 2017-02-28 isn't fixed yet. If we encounter issues during the release, we might need to postpone the release by a few days. I guess it'll be the easiest if I ping you as soon as the date and time of day is fixed. We'll know that for sure approximately one week prior to the release. I'll keep you in the loop regarding this.

comment:4 Changed 3 years ago by lisabielik

@mario

Should the third bullet point below "During an error the following data is sent" read:

Timestamp of when the error happened.

NOT:

Timestamp of when the crash happened.

Also, I added commas after "During a crash" and "During an error."

comment:5 Changed 3 years ago by lisabielik

  • Description modified (diff)

comment:6 Changed 3 years ago by mario

  • Description modified (diff)

Thanks for reviewing the text! Good catch, yes, that should be "error" instead of "crash". Changed the description.

@saoyanm, the changes are hereby approved legally and text-wise.

comment:7 Changed 3 years ago by juliandoucette

  • Cc jnink jeen added

comment:8 Changed 3 years ago by juliandoucette

  • Cc lisabielik added

comment:9 Changed 3 years ago by juliandoucette

  • Description modified (diff)
  • Priority changed from Unknown to P2
  • Ready set
  • @mario careful with those utf8 bullets and get your heading levels straight... sheesh :D
    • (Thank you for the very detailed ticket <3)
  • The privacy policy on abp.org is implemented in HTML
    • Therefore we must be careful to convert this markdown properly (preserving changed/unchanged strings, fix tags, abbreviations, etc)

comment:10 Changed 3 years ago by juliandoucette

  • Description modified (diff)

comment:11 Changed 3 years ago by juliandoucette

  • Description modified (diff)

comment:12 Changed 3 years ago by mario

@juliandoucette, thanks for triaging the issue.

and get your heading levels straight

Damnit -- that's what happens if you just guess instead of actually looking it up. :D

careful with those utf8 bullets [...] Therefore we must be careful to convert this markdown properly

For future tickets, what's the preferred format for text changes like this? I assume, that providing it in markdown would be rather error prone (if the ticket creator is neither a front end developer nor a content developer).

comment:13 Changed 3 years ago by juliandoucette

Damnit -- that's what happens if you just guess instead of actually looking it up. :D

FWIW your headers were more semantically correct ;) (because sections in HTML5 are supposed to start with H1)

For future tickets, what's the preferred format for text changes like this? I assume, that providing it in markdown would be rather error prone (if the ticket creator is neither a front end developer nor a content developer).

If the ticket creator was not a developer or manager at eyeo, and I understand the product design process correctly, than that indicates that the requested change has probably not gone through the product design process. As a result, it is the responsibility of the websites module owner and/or the websites product manager to get the request into the product design process so that it can be updated and resolved accordingly.

Also, I created a handy Markdown guide :)

comment:14 Changed 3 years ago by mario

If the ticket creator was not a developer or manager at eyeo, and I understand the product design process correctly, than that indicates that the requested change has probably not gone through the product design process.

I hope that is a misunderstanding, as it would be a great loss if that process forbid anyone outside of those groups to create tickets (i.e. proposals). But it's good that you brought this up as there's an upcoming meeting regarding this topic. I'll add that to the agenda. :)

Sorry for going off topic. Now that the issue is ready, I'll give you a heads-up as soon as the deadline is set in stone.

comment:15 Changed 3 years ago by mario

  • Description modified (diff)

Due to the current situation with Salsita, we've delayed the golive of ABB 1.5.2 by 2 weeks. This also postpones the deadline of this change
from 2017-02-28 to 2017-02-14.
I will, as promised before, give you a heads-up one week prior to the golive.

comment:16 Changed 3 years ago by mario

Quick update regarding the release of ABB, which is the reason why this ticket has a deadline. We're still in time, however we're experiencing some last minute issues, which we're currently fixing. This means:

  • We're still aiming for a release on March 14th, one week from today.
  • We might need to postpone the release a few days, in which case I'll notify you beforehand.

The changes, however, can go live on March 14th if that's easier for you to handle, even if the release of ABB is postponed by a few days.

comment:17 Changed 3 years ago by Shikitita

@saroyanm @juliandoucette I already have the translations ready for this text. Please let me know when you will be able to update the source text in Crowdin so I can add them. :)

comment:18 Changed 3 years ago by mario

We're ready for the release of ABB and aim for May 2nd. We might be a bit early depending on Apple's reaction time but updating the privacy policy by that date is absolutely sufficient.

comment:19 Changed 3 years ago by juliandoucette

  • Cc wspee added

Shouldn't this go on adblockbrowser.org?

comment:20 Changed 3 years ago by jnink

@juliandoucette: we should definitely have a privacy policy link on adblockbrowser.org.
But as we don't have a separate privacy policy yet, let's include the wording in the existing abp privacy policy and include this privacy policy on adblockbrowser.org, too.
Does that make sense?

comment:21 Changed 3 years ago by juliandoucette

  • Keywords goodfirstbug added
  • Owner set to juliandoucette

@juliandoucette: we should definitely have a privacy policy link on adblockbrowser.org.
But as we don't have a separate privacy policy yet, let's include the wording in the existing abp privacy policy and include this privacy policy on adblockbrowser.org, too.
Does that make sense?

Yes.

The change to adblockbrowser.org will require another ticket. Will you please send a request to Jeen for this? (Because I will need to know where the link should appear on adblockbrowser.org.)

comment:22 Changed 3 years ago by juliandoucette

Note: The attached RTF is out-of-sync with the text in the description. I'm implementing based on the text in the description.

comment:23 Changed 3 years ago by juliandoucette

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing
Note: See TracTickets for help on using tickets.