Closed Bug 514817 Opened 15 years ago Closed 14 years ago

update aboutRights content

Categories

(Toolkit Graveyard :: XULRunner, defect)

Product:
Toolkit Graveyard
Component:
XULRunner
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking2.0 beta7+)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: Gavin, Assigned: Margaret)

References

Details

(Whiteboard: [strings])

Attachments

(6 files, 9 obsolete files)

Revised AboutRights and Web Services Agreements
18.29 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
Revised AboutRights and Web Services Agmnts (Clean)
17.00 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
Web Services Agmnt w/disable function (mock-up)
13.49 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
patch-final
13.55 KB, patch
sdwilsh
: review+
Details | Diff | Splinter Review
final screenshot (unexpanded)
163.62 KB, image/png
Details
final screenshot (expanded)
327.68 KB, image/png
Details 
I missed this while fixing bug 513023 :(

Means the "branded" file isn't usable outside of Firefox for the moment. Fennec will have to override that DTD until this is fixed.
What does that mean for string freeze?
We should get a proper fix/factorization for this for 1.9.3.
blocking2.0: --- → ?
We should take the about:rights rewording into this bug.
1.  When the original AboutRights and Web Services Agreements were drafted, we only had one web-based service, Safe Browsing.  Since then we have added the location aware service, for which Google is the current service provider,and may add additional web-based services to Firefox in the future.  We reviewed our current Web Services Agreement to see if the current language scales to additional services and found that it could be improved. 

Attached is the redline marked to show the changes to both agreements.  I will also attach a clean version, if that's is easier to work with.

2. Create a link in "Help" that goes directly to the agreements.  Right now it's hard to see them after your initial view when you first download.

I think the current thought is to get this in Firefox 3.7.  Since this is going in a later version, do we have time now to incorporate a disabling feature rather than just showing the instructions on how to disable?

Let me know if you have any questions or something is not clear.
Clean version of the agreements.  No redlining.
In case we have time to incorporate the disable function, I've attached a rough mock up of the Web Services Agreement with this feature and the changes required  to the language.

Let me know if you have any questions.
So whilst we're here, can we either make this file more generic across apps or
make it more flexible? - especially now it is in toolkit/

For instance:

- geolocation mainly uses Google (except I think Linux will now use other
devices). Google doesn't allow non-Firefox apps to use their service currently.

- Safe browsing, I'm not actually sure Thunderbird uses that (yet), but we
point to the add-ons update service instead.
We'll want to have different sections which different products can turn on or off as they require, I imagine.
Target Milestone: --- → mozilla1.9.3a1
I was thinking about the lines of having a generic aboutRights.xhtml, which would include an chrome://content/global/aboutApp.dtd actually having no content, which could then be overloaded by apps to host content, localized by an aboutApp.dtd in locales. If that makes any sense the way I type it.

<!DOCTYPE html [
<!ENTITY % appRightsContent SYSTEM "chrome://global/content/aboutAppRights.dtd" >
<!ENTITY % appRightsLocale SYSTEM "chrome://global/locale/aboutAppRights.dtd" >
%appRightsLocale;
]>
<html>
...
%appRightsContent;
</html>

Somewhat like this. Kinda depends if we can agree to put all the app-specific content into one chunk.
Not sure it's the best idea to combine these two things into one bug, but I guess that ball's already rolling.
Summary: toolkit aboutRights.dtd refers to Firefox strings → update aboutRights content and refactor it to be usable from multiple apps (aboutRights.dtd refers to Firefox strings)
Depends on: 559609
Blocks: 559816
Blocking on getting the about:rights wording changes in I think (not sure why that is lumped into this bug).
blocking2.0: ? → beta1+
--> beta2+, maybe even further? :)
blocking2.0: beta1+ → beta2+
Yes, further! Needs to be resolved in time for string freeze I suspect!
blocking2.0: beta2+ → betaN+
Whiteboard: [strings]
Assignee: nobody → margaret.leibovic
The change in intro point 2 introduced in bug 541761 is not reflected in the revised agreements attached to this bug. Is there a newer version of the agreements that includes this change?

Also, the change introduced in bug 541761 includes the word "Firefox" instead of "&brandShortName;". Should that be changed for localization purposes?
Margaret - you can see the language currently in Firefox by going to about:rights. I haven't checked to see whether it differs from the docs that were attached to this bug a year ago.
I just wanted to make sure I was updating the language correctly. Currently in Firefox 3.6.8 the policy is (this is also what is included in the attachment):

"Mozilla does not grant you any rights to the Mozilla and Firefox trademarks or logos. Additional information on Trademarks may be found here."

However, the patch in bug 541761 changed the language to (this is what's on trunk right now):

"You are not granted any trademark rights or licenses to the trademarks of the Mozilla Foundation or any party, including without limitation the Firefox name or logo. Additional information on trademarks may be found here."

Since the attached docs are older than the changes in bug 541761, it seems like the language in the tree right now is correct. However, I think we do still need the localization fix.

I'll work on updating the other changes from the docs and get a patch up soon :)
(In reply to comment #16)
> Also, the change introduced in bug 541761 includes the word "Firefox" instead
> of "&brandShortName;". Should that be changed for localization purposes?

No, since we're talking specifically about the trademark itself. We wouldn't want "Firefox" in that sentence to be replaced with "Minefield" in nightly builds, since Minefield isn't trademarked. brandShortName is more for rebranding than it is for localizing - we don't really support localizing "Firefox" as an application name in any way.
Ah, I understand. Thanks for clarifying.
PS: official branding is localized, and some localizations actually do that. Though I think we're generally only transcribing it.
(In reply to comment 18)
Just wanted to confirm that yes, the trademark language in the tree is correct.
Attached patch patch (obsolete) — — Splinter Review 

        Attachment #467485 -
        Flags: review?(dolske)

    
    

    
  

      
      
      
      

        Attached image
          
        screenshot of new about:rights page (obsolete)
        — 
      

    


  

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch (obsolete)
        — 
          — Splinter Review
      

    


  
Oops, I had to fix the formatting on the patch to make it suitable for review.

        Attachment #467485 -
        Attachment is obsolete: true

        Attachment #467491 -
        Flags: review?(dolske)

        Attachment #467485 -
        Flags: review?(dolske)

    
    

    
  
(In reply to comment #21)
> PS: official branding is localized, and some localizations actually do that.
> Though I think we're generally only transcribing it.

I thought we'd decided that wasn't a good idea and discouraged it. Anyhow, it doesn't matter anyways, since we also don't want the transcriptions in this string.

    
    

    
  
Comment on attachment 467491 [details] [diff] [review]
patch

>diff --git a/toolkit/locales/en-US/chrome/global/aboutRights.dtd b/toolkit/locales/en-US/chrome/global/aboutRights.dtd

>-<!ENTITY rights.webservices-c " section, and unchecking the options for &quot;&blockAttackSites.label;&quot; and &quot;&blockWebForgeries.label;&quot;">

>+<!ENTITY rights.safebrowsing-term3 "Uncheck the options to &quot;Block reported attack sites&quot; and &quot;Block reported web forgeries&quot;">

Looks like this removes the dependency on chrome://browser/locale/preferences/security.dtd? Should stop including it in aboutRights.xtml, if so, and add an l10n note here (per https://developer.mozilla.org/en/xul_coding_style_guidelines#Localization_Notes ) that these strings should be taken directly from that file.

    
    

    
  
I made an error and will fix it to keep the dependency. I just copy/pasted from the attached docs and missed that.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch-v2 (obsolete)
        — 
          — Splinter Review
      

    


  
Fixed localization issue from comment 27

        Attachment #467491 -
        Attachment is obsolete: true

        Attachment #467500 -
        Flags: review?(dolske)

        Attachment #467491 -
        Flags: review?(dolske)

    
    

    
  
Hmm, it might actually be nice to remove the dependency (it would fix this bug as originally filed, which would allows us to undo bug 514818, and would make fixing bug 559816 / bug 513025 easier). But I guess that's best done separately at this point.
Summary: update aboutRights content and refactor it to be usable from multiple apps (aboutRights.dtd refers to Firefox strings) → update aboutRights content
No longer blocks: 559816, 513023, 531798
No longer depends on: 559609

    
    

    
  
I filed bug 588916 to cover the original issue.

    
    

    
  
Comment on attachment 467500 [details] [diff] [review]
patch-v2

The changed strings should get their ids changed, so that l10n picks these changes up.

        Attachment #467500 -
        Flags: feedback-

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch-v3 (obsolete)
        — 
          — Splinter Review
      

    


  
Changed names for changed strings.

        Attachment #467500 -
        Attachment is obsolete: true

        Attachment #467829 -
        Flags: review?(dolske)

        Attachment #467829 -
        Flags: feedback?(l10n)

        Attachment #467500 -
        Flags: review?(dolske)

    
    

    
  
Comment on attachment 467829 [details] [diff] [review]
patch-v3

I'm not so fond of the mix between rights... and rights2..., but for the lack of a better idea, feedback+.

        Attachment #467829 -
        Flags: feedback?(l10n) → feedback+
blocking2.0: betaN+ → beta5+

    
    

    
  
Legal should review the content of the About Your Rights page to make sure we don't need to update it. If we do have changes, would we submit them here or open a new bug? How quickly would we need to provide the updates? We may not have any, but need to check to see.

    
    

    
  
The mockup we used came from legal - if you need further review, please expedite. Your window is basically Thursday EOD.

    
    

    
  
I just want to make sure with new product features in 4 that we don't need to add anything to the web services information. If we have updates, we'll submit by EOD Thursday.

    
    

    
  
Here's what we'd like to add to the About Rights page.

1) Change the privacy policy bullet point to say "Privacy policies for Mozilla Firefox may be found here."

2) Add another bullet point that says "Some Firefox features allow you to submit feedback to Mozilla. More information may be found here."

3) Add the following new section after the Web Services section linked from the word "here" in this new bullet point:

Feedback you Provide

Several features in Firefox allow users to provide information and feedback to Mozilla, including Mozilla Crash Reporter, the Report Broken Websites form, and the Feedback button. We use the information provided to fix problems, identify new features to add, and other related purposes. Receiving this information from users really helps us build better products. Some of these feedback mechanisms allow you to include your email address. This is always optional. The information received through these mechanisms is usually posted publicly, sometimes individually, and sometimes in the aggregate.  You should not include any personal information in the forms you fill out for any of these features, unless you are okay with it being public (this might include URLS that include your name or password and your email address or other contact information). You are not required to submit any information but if you choose to use these services, we appreciate your help in making Firefox better.

By submitting feedback, you authorize Mozilla to reproduce, use, display, process, modify, and distribute that feedback.

For more information on these feedback tools, please see the Firefox Privacy Policy.

    
    

    
  
Hey Liz - this is a little longer than I was anticipating. It's also not really written in the spirit of about:rights, which is to take legal language and make it easy and quick to understand. 

Can we collapse it down into a single bullet, like:

* Several features in Firefox give you the option to provide feedback to Mozilla. By choosing to submit feedback, you give Mozilla permission to use the information to improve Firefox, and to publish the feedback on its websites. Any information you provide will be subject to the Firefox Privacy Policy.

with that last bit linking to the privacy policies.

The advantage here is that the important text isn't hidden in an area that's non-visible by default, and the main point (we're allowed to use the information as governed by the privacy policy) is right there for everyone to see.

The disadvantage is that we lose a lot of the (great!) caveats about not including personal information in that feedback. My feeling, though, is that these caveats are better placed at the point that we're collecting the information (which we already do, happily, in Crash Reporter) - that way users aren't expected to think back to something they read in about:rights long ago.

    
    

    
  
Hi, Mike.  I'll try to respond to your comment to Liz since I know we're on a tight deadline.  (Liz and I worked closely on this.)

Yes, we can certainly try to shorten it.  But some of this we do need to spell out since its not anywhere else (like granting us the right to use feedback).

What do you think of this attempt to meld the two versions (its down from 19 lines to 8)?:

Features in Firefox allow users to provide information and feedback to
Mozilla (like Mozilla Crash Reporter, the Report Broken Websites form, and
the Feedback button). We use the information provided to fix problems, identify
future features, and other related purposes.  By submitting feedback, you authorize Mozilla to reproduce, use, display,process, modify, and distribute that feedback.  Some of the comment fields in these features are posted publicly, so don't include any personal details there.  For more information on these feedback tools, please see the Firefox Privacy Policy.

    
    

    
  
(In reply to comment #40)
> Yes, we can certainly try to shorten it.  But some of this we do need to spell
> out since its not anywhere else (like granting us the right to use feedback).

Yup, that makes sense; the key here is that granting of right to use feedback, right?

> Features in Firefox allow users to provide information and feedback to
> Mozilla (like Mozilla Crash Reporter, the Report Broken Websites form, and
> the Feedback button). 

^^^ let's not name the services; Report Broken Websites has been removed in Firefox 4, and the Feedback Button only exists for beta testers. I don't think we want to have to maintain this list, esp. since it's not exhaustive.

> We use the information provided to fix problems, identify
> future features, and other related purposes. By submitting feedback, you
> authorize Mozilla to reproduce, use, display,process, modify, and distribute
> that feedback. 

^^^ this is where I was hoping to shorten by saying "You give Mozilla permission to use that information to make Firefox better." I think that's understandable/interpretable, and is about as specific as "other related purposes." Do we have to say "use, display, process, modify and distribute"? I like how we've avoided legal boilerplate, and was hoping we could get there with the more approachable "use the information to improve Firefox, and can publish the information on public websites."

> Some of the comment fields in these features are posted
> publicly, so don't include any personal details there.  For more information 
> on these feedback tools, please see the Firefox Privacy Policy.

^^^^ this bit, specifically, seems out of place here. I think we should reference the privacy policy, but the best place to give people warnings about not posting things they don't want seen publicly is at the point when they're writing them (so, in Firefox Input and in Crash Reporter - happily, both of those places contain those warnings)

    
    

    
  
^^^ let's not name the services; Report Broken Websites has been removed in
Firefox 4, and the Feedback Button only exists for beta testers. I don't think
we want to have to maintain this list, esp. since it's not exhaustive.

JAM:  We try to be specific when we reference services or features.  Here we listed the parenthetical as examples so that we wouldn't have to update but that users would have a sense of exactly what we meant.  If Report Broken Websites was pulled, let's just list the other two as examples.  Also, we heard that TP (and Feedback??) were going in Fx4.  We've been trying to get confirmation.  So, if that is being pulled, I think we can just list Crash Reporter as an example.

^^^ this is where I was hoping to shorten by saying "You give Mozilla
permission to use that information to make Firefox better." I think that's
understandable/interpretable, and is about as specific as "other related
purposes." Do we have to say "use, display, process, modify and distribute"? I
like how we've avoided legal boilerplate, and was hoping we could get there
with the more approachable "use the information to improve Firefox, and can
publish the information on public websites."

JAM:  These terms are each granting us a right so I think of all the places, this is probably toughest to shorten up and make less legal.  In copyright and other areas of ip, there are a variety of enumerated rights.  Also, our purpose may not always be limited to Firefox.  We may use the feedback to improve other products or tools.  So we actually put a fair bit of time into this language.  That said, I don't see why process is in there.  So, I'd be okay removing that one.

^^^^ this bit, specifically, seems out of place here. I think we should
reference the privacy policy, but the best place to give people warnings about
not posting things they don't want seen publicly is at the point when they're
writing them (so, in Firefox Input and in Crash Reporter - happily, both of
those places contain those warnings)

JAM:  We gave gotten some grief lately over the fact that things people post on some pages (like Hendrix) ended up on the web.  Even though we put large warnings out there on websites disclosing this.  So, we wanted to be upfront for those users that are sensitive.  Also, the privacy policy doesn't really highlight this.  That said, if we have warnings in the dialogue boxes in CR and the feedback tool...that is great.  I wasn't sure it came up before you submitted comments in CR.  That is likely recent if it's there.  Do you know what it says exactly and where?  

What is Firefox Input?

    
    

    
  
(In reply to comment #42)
> JAM:  We try to be specific when we reference services or features.  Here we

Not sure what we gain by being specific; doesn't that set up an expectation that the list is exhaustive and thus limiting the granted right for use? We list specific services for the Web Services section because there are specific additional terms of service depending on the service in question; that's not the case here.

> that TP (and Feedback??) were going in Fx4.  We've been trying to get
> confirmation.  So, if that is being pulled, I think we can just list Crash
> Reporter as an example.

It's there if the user has the add-on, but as per our conversations before beta 1 we're not shipping Test Pilot (which is the same as the Feedback Add-On) as part of Firefox 4, no.

> JAM:  These terms are each granting us a right so I think of all the places,
> this is probably toughest to shorten up and make less legal.  In copyright and
> other areas of ip, there are a variety of enumerated rights.  Also, our 

How are we planning on distributing the information? How are we planning on modifying it? I don't think we're going to do anything beyond "use" and "display", but am curious to know if I'm missing a nuance of those words. We've been trying to avoid legal nuance terms elsewhere in this document, and I'd like to keep this as plain as possible.

> purpose may not always be limited to Firefox.  We may use the feedback to 
> improve other products or tools.  So we actually put a fair bit of time into 
> this language. That said, I don't see why process is in there.  So, I'd be 
> okay removing that one.

Heh, of course you put time into it; not meaning to imply otherwise. Good point about changing it to "products" instead of "Firefox".

> JAM:  We gave gotten some grief lately over the fact that things people post > on some pages (like Hendrix) ended up on the web.  Even though we put large
> warnings out there on websites disclosing this.  So, we wanted to be upfront
> for those users that are sensitive.  Also, the privacy policy doesn't really

I understand and agree with the motivation, I just think this is the wrong place. At the time the user is reading this document, they aren't submitting feedback, and so the warning is less useful; we've already made it clear (above) that users grant us the right to "display".


> highlight this.  That said, if we have warnings in the dialogue boxes in CR and
> the feedback tool...that is great.  I wasn't sure it came up before you
> submitted comments in CR.  That is likely recent if it's there.  Do you know
> what it says exactly and where?  

It's not recent: http://i.nconspicuo.us/wp-content/uploads/2008/07/mozilla-firefox-crash-reporter.png ("Comments are publicly visible" right where we ask for comments).

> What is Firefox Input?

http://input.mozilla.com/en-US/happy is what we use to collect feedback now instead of the Submit Broken Website form

    
    

    
  
New version based on Julie's comments and my last proposal:

* Some features in Firefox such as the Crash Reporter give you the option to provide feedback to Mozilla. By choosing to submit feedback, you give Mozilla permission to use the feedback to improve its products, to publish the feedback on its websites, and to distribute the feedback. Any feedback you provide will be subject to the Firefox Privacy Policy.

That work for you, Julie?

    
    

    
  
Yes.  Thanks, Mike.

    
    

    
  
Margaret; can you add the bullet from comment 44 to your patch? I think above the Web Services bullet, and remember to link to the privacy policy, please and thank you!
Whiteboard: [strings] → [strings][see comment 44]

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch-v4 (obsolete)
        — 
          — Splinter Review
      

    


  
I updated the patch to add a bullet point about user feedback.

I replaced the "Privacy policies for Mozilla's products may be found here." bullet point with the bullet point text from comment 44 because it seemed redundant to have a link to the privacy policy in two places. I also made the link text "Mozilla Privacy Policy" instead of "Firefox Privacy Policy" because the webpage it links to (http://www.mozilla.com/legal/privacy) isn't Firefox specific.

        Attachment #467829 -
        Attachment is obsolete: true

        Attachment #470006 -
        Flags: review?(dolske)

        Attachment #467829 -
        Flags: review?(dolske)

    
    

    
  
Comment on attachment 470006 [details] [diff] [review]
patch-v4

Hm, I see what you mean about the redundancy. The privacy policy applies to more than just the feedback stuff, though. Let's do this instead:

* Some features in &brandShortName;, such as the Crash Reporter, give you the option to provide feedback to &vendorShortName;. By choosing to submit feedback, you give &vendorShortName; permission to use the feedback to improve its products, to publish the feedback on its websites, and to distribute the feedback.

* Your personal information, including any feedback submitted to Mozilla, is protected by the Firefox Privacy Policy.

        Attachment #470006 -
        Flags: review?(dolske) → review-

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch-v5 (obsolete)
        — 
          — Splinter Review
      

    


  
Addressed feedback from comment 49.

        Attachment #470006 -
        Attachment is obsolete: true

        Attachment #470023 -
        Flags: review?(beltzner)

    
    

    
  


  

        Attachment #470008 -
        Attachment is obsolete: true

    
    

    
  
While it seems innocuous, these new changes may have legal implications.  If we're going to change what was agreed to this morning, please give us legal folks a chance to weigh in.

    
    

    
  
Here's our revised proposal for the privacy policy bullet point:

* How we use your personal information and feedback submitted to Mozilla through Firefox is described in the Firefox Privacy Policy.

Sound OK?

    
    

    
  
Sounds fine, though it requires a new patch. :( I'm not really sure how your version differs, and am not really happy with the word "use" in there as opposed to "protected" which I'd included pretty intentionally (as it shifts the focus from Mozilla using to Mozilla protecting).

Margaret: please alter based on comment 53 and poke dolske for review?

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch-final
        — 
          — Splinter Review
      

    


  
Updated patch with final language decision.

        Attachment #470023 -
        Attachment is obsolete: true

        Attachment #470436 -
        Flags: review?(dolske)

        Attachment #470023 -
        Flags: review?(beltzner)

    
    

    
  


  

        Attachment #470026 -
        Attachment is obsolete: true

    
    

    
  


  

        Attachment #467486 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 470436 [details] [diff] [review]
patch-final

r=sdwilsh

        Attachment #470436 -
        Flags: review?(dolske) → review+

    
    

    
  
Axel has asked that we not check this in until after beta5 is tagged so that we don't churn the l10n this late; we'll get it for beta6. Thanks, everyone.
blocking2.0: beta5+ → beta6+
Whiteboard: [strings][see comment 44] → [strings][do not land until after b5]

    
  
Keywords: checkin-needed

    
    

    
  
I don't know if there's much time left for changes, but if you'd like to talk about ways to reword the language in comment 53, we can do that. Protect is a tricky word in this context, but would handle or manage be better than use?

    
  
Whiteboard: [strings][do not land until after b5] → [strings]
Target Milestone: mozilla1.9.3a1 → ---

    
    

    
  
http://hg.mozilla.org/mozilla-central/rev/c8bf9ce70506
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED

    
  
Keywords: checkin-needed

    
    

    
  
<!ENTITY rights.safebrowsing-term2 "Select the Security selection">

I suppose that "selection" should be "section" or "panel"

    
    

    
  
(removing dependency on bug 571584)
No longer depends on: 571584

    
    

    
  
(In reply to comment #62)
> <!ENTITY rights.safebrowsing-term2 "Select the Security selection">
> 
> I suppose that "selection" should be "section" or "panel"

Hmm, I got that string from copy/pasting the language in the attached documents. Should we file a new bug to change this?

    
    

    
  
Also, the disclaimer for Location Aware Service in the rights2.webservices-term1 entity looks awkward.
"For example, the Safe Browsing Service may not identify some risky sites and may identify some safe sites in error and the Location Aware Service all locations returned by our service providers ..."

    
  
Depends on: 599669
Product: Toolkit → Toolkit Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: