Closed Bug 281717 Opened 20 years ago Closed 19 years ago

reporter needs a privacy policy

Categories

(Other Applications Graveyard :: Reporter, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: raccettura, Assigned: rebron)

References

()

Details

Attachments

(1 file, 3 obsolete files)

reporter has blank space for a privacy policy. Since we collect some information, and pride ourselves on security, and respecting privacy.... it's very important to be be clear that reporter only captures information when it's submitted by the user. - We capture IP address, but it's only revealed to a group of admins as appointed by MoFo on a need basis. - We use a unique tracking number for the sole purpose of being able to tell if someone submits a site X number of times, or if a number of people submit a website once. The tracking number is _not_ used for any other purpose. It's not linked to any other information or used in any other way. Talkback apparantly is able to individualize users because it captures a ton of info about the user's system. We don't do that. - Email is 100% optional - For all non-admin's, reports are santized (no IP, email, id) shown. - Still debating if we should hide all https url's by default from non-admin's. We can change this at any time by tweeking the webtool. I'm not of the belief that this provides any additional security. More research will be needed.
Attached patch Patch to add privacy link (obsolete) (deleted) — Splinter Review
While were waiting on a privacy thing we should do a few things: - note email is optional - add a privacy link in the report area made openURL(aURL) like I did so that in the future we can use it to make the report results <wizardpage> linkable (should we decide to do so). Any status on the actual privacy policy?
Asking to block, as we really need to have this for the tin-foil-hat audience.
Flags: blocking1.8b3?
Attached patch Better (obsolete) (deleted) — Splinter Review
Better: Show header and footer when launching url, don't show in privacy frame.
Attachment #182503 - Attachment is obsolete: true
Attached patch Betterer (obsolete) (deleted) — Splinter Review
Even betterer
Attachment #182510 - Attachment is obsolete: true
Attached patch Betterest (deleted) — Splinter Review
Attachment #182517 - Attachment is obsolete: true
Comment on attachment 182520 [details] [diff] [review] Betterest >+function openPrivacyPolicy() { >+ var aURL = getCharPref("privacyURL", "http://reporter-test.mozilla.org/privacy/"); >+ openDialog("chrome://browser/content/browser.xul", "_blank", "chrome,all,dialog=no", aURL, null, null); >+} just var url here, the a prefix is for function args. r=mconnor@steelgryphon.com
Attachment #182520 - Flags: review+
checked in with a=asa The rest is for mitchell ;-)
Assignee: mitchell → rebron
>- We use a unique tracking number for the sole purpose of being able to tell if >someone submits a site X number of times, or if a number of people submit a >website once. could we, for increased privacy, hash that ID with the site URL? that'd still allow telling those two cases apart, but not allow telling whether a user submitted different sites.
(In reply to comment #8) > > could we, for increased privacy, hash that ID with the site URL? that'd still > allow telling those two cases apart, but not allow telling whether a user > submitted different sites. problem there is we are open to anything in the world. Defeating the system: currently, when you agree to the privacy policy, we give you a token. Just a random hash. When you submit, you give it back. If we hash the ID with the URL, we get unique users, but we have no way of telling if that's unique, or just some script kiddy sending us random garbage (unless we compare that hash to our entire database, which isn't an option obviously). It also allows us to shut people out, should they just decide to send stupid reports and become a real burdon. We can nix their ID, and block them from creating a new one. IMHO it's no more intrusive than a cookie. Since that's essentially all it is.
>We can nix their ID, and block them from creating a new one. all you can do is block their IP, no? and they tend to be dynamic.. >IMHO it's no more intrusive than a cookie. Since that's essentially all it is. but users can have cookies expire at the end of the session.
I should also add that talkback does the same thing by collecting enough info about the computer (I assume that's a combo of hardware/software characteristics). So were not intruding on privacy any more than talkback is. And again, it only happens if you choose to participate. You never contact the reporter service until you agree to the privacy policy. The token is created when you agree and continue on. talkback individualizes by creating enough of a profile that your computer is unique. We just give you a hash. IMHO your much more anonymous on reporter than talkback. We know almost nothing about you.
need this before we ship, probably before we ship the end-user beta (1.8b4)
Flags: blocking1.8b4+
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Flags: blocking-aviary1.1+
It's server side, so we can technically do it anytime, and effect all builds. The only issue here is if we are going to localize it for other languages (or does everyone get en-US)? If we localize, we need to give them some time for them to post translations so I can upload them to the server. We can do this on the fly of course, the default will be en-US.
Yes, a localized privacy policy is pretty important. A privacy policy in some foreign language in a localized browser would immediately raise suspicion among the non-English speaking tin-foil-hat audience. "Hmm, they are trying to hide something from me." :)
Localizing it may create some very serious legal issues itself. This is something that will need to be discussed.
(In reply to comment #15) > Localizing it may create some very serious legal issues itself. This is something that will need to be > discussed. Yes. The same we're facing with other issues. The difference is that user is familiar with some "boring licenses" in the installer, but facing some new tool and being unable to read it could give user _very_ bad experience with Firefox. We overall trust our locale teams - we can, with no problem, write very precize description on how to localize privacy policy and, if needed, ask OpenOffice l10n teams to verify that. But, IMHO, we simply can't give such important piece of our application untranslated.
those translations should probably mention that only the english version is the one to be trusted, then.
(In reply to comment #17) > those translations should probably mention that only the english version is the > one to be trusted, then. Yes, that's the obvious part of every license translation. At the end one put sentence like: "This is privacy policy translation made for your convenience. Only original, english version has formal power".
I think having translations of the policy is a fine idea. The best thing to say is probably as follows, in both English and the translated language. This text is modelled on the FSF's disclaimer for the GPL. "This is an unofficial translation of the Reporter Privacy Policy. Only the original English text of the policy is official. However, we hope that this translation will help speakers of this language understand the policy better." Gerv
Blocks: branching1.8
Whiteboard: [massively affects l10n]
I personally don't care about leaving [massively affects l10n], but I'm not so sure it's needed. Because it's all server side, we can deploy new localizations at any given time, even after release. So were not exactly bound to the same time restrictions that the the branch is.
I was confused then, Asa led me to believe that this was a client-side change.
No longer blocks: branching1.8
Whiteboard: [massively affects l10n]
*** Bug 302619 has been marked as a duplicate of this bug. ***
rafael, could you please make sure our new privacy policy covers this and post to reporter.mozilla.org? thanks /cb
privacy policy does cover the reporter tool: http://www.mozilla.org/privacy-policy.html Can we point the reporter tool privacy policy url to the one above.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
We technically can, but I'd perfer to leave it on the reporter server, so we can have a text only version, and a version within the page design. Not to mention we can let people localize. rebron: is it ok for me to copy the text into the current production instance? And set things up for localization of that text? (or should we wait until it doesn't say draft on it?)
I'd prefer we keep the privacy policy centralized and treat it like how we have the EULA: http://www.mozilla.org/foundation/EULA/
Rafael: but this will block us from localizing it, right? And if so, it will be a high-severity l10n issue as described previously in this bug.
Flags: blocking-aviary1.5+
is this fixed for 1.8b5 as well? If so, can you add the fixed1.8 keyword to it? Otherwise if it needs to land there we need to add the late-l10n keyword as well.
I'm waiting on word from Asa on how to approach this. Last we talked, perhaps the website would adjust so that we can point the reporter server to redirect to it (rather than host it on the reporter server). I think regardless, the change will be server side, not client side. At most a pref change.
please, let's solve it sooner than later. We should not wait for the last second, because there'll be no time and l10n builds will be released with english policy :/ Axel is now in charge, so maybe he want to say something?
Privacy Policy will *not* be client side, so we can do this even after it ships (though ideally before). So we aren't bound to the same time constraints as Firefox is.
> so we can do this even after it ships I doubt it. After the release you will have a lot of other work to be done. And, .. well... it'll be after the release, so users will be confused already. What is the blocker at the moment?
rebron doesn't want multiple copies of the privacy policy out there. The existing one has a mozilla design around it. We need it both plain html, and with the design. We can use the server to redirect to the current copy, but we need a plain copy as well (and need them kept in sync). We'll point to the reporter server, and just have it redirect (so we can easily change on the fly, and so we can manage all reporter related server connections via the reporter server).
This is a legal document. It will remain in english for all of our releases, like the EULA. We may provide a mechanism to point to unofficial translations, but that doesn't seem like a high priority to me.
We'll have a plain-text version like how we treat the EULA: http://www.mozilla.org/foundation/EULA/ We'll host localized versions of the privacy policy there as well as we receive them. The issue with localizing legal documents is that localization requires both translation and legal review. Translation is of course easier than getting the legal review.
rebron: awesome, we can work with that (I can point the reporter server to redirect to those). Could we get a pain html version (without the mozilla.org treatment around it)? Something like: http://reporter.mozilla.org/privacy/?plain That will allow for a better appearance.
Rafael: does it mean that once we'll get a lawyer's review, you'll accept our localization? I mean - we want to get through this process, and we need to know the rules. (I mean polish team)
Reopening, as Reporter still doesn't have a complete privacy policy. http://reporter.mozilla.org/privacy/ says: "Our privacy policy is still under construction." Robert: if you want to open another bug instead, please do so. Whichever you do, the open bug should be nominated to block the final 1.5 release. Gerv
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 297835 has been marked as a duplicate of this bug. ***
Raf, can you make a plaintext version of the policy available ASAP so that we can point to that from Reporter? Thanks.
QA Contact: xul-client → asa
we need a "simple html" version, I discussed this with rebron a few days ago. The plan is to redirect the reporter server, so nothing in the client should be tweeked by this change, it's pure server side.
This wasn't functional in beta 1 and we can actually take a fix any time, including after we shio beta 2. we definitely want this but it's not going to block the release.
Flags: blocking1.8b5+ → blocking1.8b5-
Fixed right?
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
Product: Other Applications → Other Applications Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: