Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify Data Storage in user documentation #5235

Open
bbarry opened this issue Nov 29, 2024 · 1 comment
Open

Clarify Data Storage in user documentation #5235

bbarry opened this issue Nov 29, 2024 · 1 comment
Labels
documentation Both end-user documentation, and developer documentation privacy Data sanitization, and privacy concerns

Comments

@bbarry
Copy link

bbarry commented Nov 29, 2024

While it appears that profile data does not leave my machine when I load a profile (if it does then my tests were too small and I wasn't looking at the right place; reading the loading developer documentation it does seem implied to remain local) with the application at profiler.firefox.com until I click on the upload link, I cannot find anything in the user documentation describing how my profile data is handled. My employer would be very much against me using this tool to visualize our profiler data if it was possible that third parties could gain access to it. Additionally I cannot imagine mozilla wants to retain unlimited shared profiler data indefinitely.

Perhaps one day we could sign in somehow and configure a different url for a share/storage backend that we could self host or disable the upload/share option. For now just some high level documentation about how the profile data is loaded/shared would be appreciated.

What I'm expecting:

Some high level documentation to the effect of:


Profile Data Usage at https://profiler.firefox.com:

  • Your data when using a loaded profile via the load profile button remains in the session/cache data of your browser hosting an active session on the site. It is not sent to the host of profiler.firefox.com or any other server unless you choose to do so.
  • Your data when loading a profile from a url is hosted at the specified url outside of the control of mozilla and requires that the host of that url configures CORS headers properly such that the application running locally from within the https://profiler.firefox.com context can access the data. It is not sent to the host of profiler.firefox.com or any other server unless you choose to do so.
  • If you upload a local profile, it is sent to https://api.profiler.firefox.com where it is publicly available.
    • By default, uploaded profiles of Firefox profiling data do not contain sensitive information about the Firefox installation or user data.
    • Profile data is associated with an id of the browser that uploaded it. This id is permitted 1gb of storage across Mozilla resources, for more information see...(?)
    • Profile data will be retained for up to 3 years (?)
    • Uploaded data must validate as profile data or will be immediately rejected.
    • You may delete an uploaded profile explicitly at any time.

Further control over your profile data may be achieved by becoming involved in the development of https://profiler.firefox.com and hosting your own version of the tool in accordance with the licensing terms. Mozilla welcomes and encourages active community support.


This tool is awesome btw, I found it via https://github.com/xoofx/ultra

┆Issue is synchronized with this Jira Task

@julienw
Copy link
Contributor

julienw commented Dec 2, 2024

Thanks for the write-up, indeed it would be good to include this information in our documentation. Thanks for the suggestion.

To clarify a few things:

  • Currently we do not delete any uploaded data. We use it quite extensively on bugs in bugzilla.mozilla.org and don't want to risk getting dead links on bugs that are still open.
  • We also do not have a limit on what can be uploaded in total -- we do have a limit per upload though (150 MB).

About the 3rd party access, we expect that the generated id is too random to be found by brute force.
I believe our main weakness is with our use of the bitly service though, where the search domain is much lower, and could possibly be found. I'd expect bitly to be resilient to brute forcing but last time I checked they don't protect against that.

Though I understand that a company wouldn't want any data to be shared publicly. We don't currently have a solution for that.

@julienw julienw added documentation Both end-user documentation, and developer documentation privacy Data sanitization, and privacy concerns labels Dec 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Both end-user documentation, and developer documentation privacy Data sanitization, and privacy concerns
Projects
None yet
Development

No branches or pull requests

2 participants