Closed
Bug 281717
Opened 20 years ago
Closed 19 years ago
reporter needs a privacy policy
Categories
(Other Applications Graveyard :: Reporter, defect)
Other Applications Graveyard
Reporter
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: raccettura, Assigned: rebron)
References
()
Details
Attachments
(1 file, 3 obsolete files)
(deleted),
patch
|
mconnor
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•20 years ago
|
||
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?
Reporter | ||
Comment 2•20 years ago
|
||
Asking to block, as we really need to have this for the tin-foil-hat audience.
Flags: blocking1.8b3?
Reporter | ||
Comment 3•20 years ago
|
||
Better: Show header and footer when launching url, don't show in privacy frame.
Attachment #182503 -
Attachment is obsolete: true
Reporter | ||
Comment 5•20 years ago
|
||
Reporter | ||
Updated•20 years ago
|
Attachment #182517 -
Attachment is obsolete: true
Comment 6•20 years ago
|
||
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+
Reporter | ||
Comment 7•20 years ago
|
||
checked in with a=asa
The rest is for mitchell ;-)
Assignee | ||
Updated•20 years ago
|
Assignee: mitchell → rebron
Comment 8•20 years ago
|
||
>- 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.
Reporter | ||
Comment 9•20 years ago
|
||
(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.
Comment 10•20 years ago
|
||
>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.
Reporter | ||
Comment 11•20 years ago
|
||
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.
Comment 12•20 years ago
|
||
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+
Reporter | ||
Comment 13•20 years ago
|
||
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.
Comment 14•20 years ago
|
||
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." :)
Reporter | ||
Comment 15•20 years ago
|
||
Localizing it may create some very serious legal issues itself. This is something that will need to be
discussed.
Comment 16•20 years ago
|
||
(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.
Comment 17•20 years ago
|
||
those translations should probably mention that only the english version is the
one to be trusted, then.
Comment 18•20 years ago
|
||
(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".
Comment 19•20 years ago
|
||
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
Updated•20 years ago
|
Blocks: branching1.8
Updated•20 years ago
|
Whiteboard: [massively affects l10n]
Reporter | ||
Comment 20•20 years ago
|
||
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.
Comment 21•20 years ago
|
||
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]
Comment 22•19 years ago
|
||
*** Bug 302619 has been marked as a duplicate of this bug. ***
Comment 23•19 years ago
|
||
rafael, could you please make sure our new privacy policy covers this and post
to reporter.mozilla.org?
thanks
/cb
Assignee | ||
Comment 24•19 years ago
|
||
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
Reporter | ||
Comment 25•19 years ago
|
||
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?)
Assignee | ||
Comment 26•19 years ago
|
||
I'd prefer we keep the privacy policy centralized and treat it like how we have
the EULA: http://www.mozilla.org/foundation/EULA/
Comment 27•19 years ago
|
||
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.
Updated•19 years ago
|
Flags: blocking-aviary1.5+
Comment 28•19 years ago
|
||
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.
Reporter | ||
Comment 29•19 years ago
|
||
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.
Comment 30•19 years ago
|
||
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?
Reporter | ||
Comment 31•19 years ago
|
||
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.
Comment 32•19 years ago
|
||
> 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?
Reporter | ||
Comment 33•19 years ago
|
||
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).
Comment 34•19 years ago
|
||
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.
Assignee | ||
Comment 35•19 years ago
|
||
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.
Reporter | ||
Comment 36•19 years ago
|
||
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.
Comment 37•19 years ago
|
||
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)
Comment 38•19 years ago
|
||
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
Reporter | ||
Comment 39•19 years ago
|
||
*** Bug 297835 has been marked as a duplicate of this bug. ***
Comment 40•19 years ago
|
||
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
Reporter | ||
Comment 41•19 years ago
|
||
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.
Comment 42•19 years ago
|
||
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-
Assignee | ||
Comment 43•19 years ago
|
||
Fixed right?
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Other Applications → Other Applications Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•