disabling sharing on cache-control: no-store is an unexpected limitation

VERIFIED FIXED in Firefox 23

Status

()

Firefox
SocialAPI
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: edA-qa mort-ora-y, Assigned: mixedpuppy)

Tracking

23 Branch
Firefox 24
x86_64
Linux
Points:
---

Firefox Tracking Flags

(firefox23 verified, firefox24 verified)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
The share button is disabled if a page is served with the "Cache-Control: no-store" header. This doesn't appear consistent with the intent of this header, nor with the expectations of a user.

The use of this header has also slightly diverged from the RFC, in that beyond protecting sensitive information it is sometimes used just to prevent caching of timely and/or changing information. IT doesn't make sense to block sharing when this header is used as such. Even if used correctly however the RFC has the language that a user may still explicitly store the page. One would assume this intent would also be applied to explicitly sharing the page.

Lacking any sort of feedback mechanism it won't be clear to a user why they can't share a particular page. It should also be noted that nothing stops the user from copying the URL and sharing it directly on a provider. Thus the limitation is one that a reasonable user should not expect as it is a new restriction on their behaviour.

I would recommend lifting this restriction. If it will not be lifted then at least improve the user experience. This includes presenting a message saying why they can't share a page and providing an explicit override option (for example, clicking share on such a page shows a panel with a warning, pressing a "Continue anyways" button will then bring up the normal share panel).
(Assignee)

Comment 1

5 years ago
"Cache-Control: no-store" is the only standard mechanism (I am aware of) that a site has to indicate that the content is sensitive in nature, I'd be very reluctant to remove this limitation.  However, improving UX around this, even allowing the user to bypass, is a good improvement.  Since it would involve strings, we would not be able to get this in for 23.

Boriss, any thoughts on the ux around this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jboriss)
(Assignee)

Updated

5 years ago
Duplicate of this bug: 872157
(Reporter)

Comment 3

5 years ago
Our provider allows sharing items to oneself (send by email) within a private network (like SocialCast, or LinkedIn), or simply marking it for later reading (pocket, instapaper, or our favourites). In these use cases the restriction on activating the share button doesn't make sense. It'd be like saying the no-store header also means you can't save, print, or bookmark the URL.

For an improved experience it'd be nice if this "private" flag was instead passed to the share provider who could then decide how to deal with it. In our case we could gray-out the public sharing options but still allow for private sharing. There would also be a simple override mechanism to force the public sharing.
(Assignee)

Comment 4

5 years ago
Created attachment 766121 [details] [diff] [review]
remove no-store limitation in share

Too many pages use no-store so it isn't reasonable to rely on that.  Since share requires user action, and any true sensitive data is likely behind login, thus inaccessible to the receiver of the share, we'll remove the no-store limitation.
Assignee: nobody → mixedpuppy
Attachment #766121 - Flags: review?(gavin.sharp)
Attachment #766121 - Flags: review?(gavin.sharp) → review+
(Assignee)

Updated

5 years ago
status-firefox23: --- → affected
status-firefox24: --- → affected
(Assignee)

Comment 6

5 years ago
Comment on attachment 766121 [details] [diff] [review]
remove no-store limitation in share

[Approval Request Comment]
Bug caused by (feature/regressing bug #): share feature
User impact if declined: users are unable to determine why share is disabled, can seem to be broken.
Testing completed (on m-c, etc.): m-c
Risk to taking this patch (and alternatives if risky): low
String or IDL/UUID changes made by this patch: none
Attachment #766121 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/mozilla-central/rev/75948a6ea38d
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24

Updated

5 years ago
status-firefox24: affected → fixed

Updated

5 years ago
Attachment #766121 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
(Assignee)

Updated

5 years ago
Flags: needinfo?(jboriss)
Comment on attachment 766121 [details] [diff] [review]
remove no-store limitation in share

[Approval Request Comment]
Missed the Aurora train. Needs beta approval.
Attachment #766121 - Flags: approval-mozilla-aurora+ → approval-mozilla-beta?
Attachment #766121 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Shane, is there a desire for QA verification here?
Flags: needinfo?(mixedpuppy)
(Assignee)

Comment 11

5 years ago
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #10)
> Shane, is there a desire for QA verification here?

Verification would be that the share icon is enabled/usable on any page (Facebook pages are a good test case, you couldn't click the share button on any of them).
Flags: needinfo?(mixedpuppy)
Samvedana, can you please verify this is fixed in Firefox 23 and 24? Best try on several different Facebook pages just to be sure. Thanks.
Keywords: verifyme
QA Contact: samvedana.gohil
(Assignee)

Comment 13

5 years ago
You should be able to verify the page has the no-store header via the page info dialog.
(Assignee)

Comment 14

5 years ago
(In reply to Shane Caraveo (:mixedpuppy) from comment #13)
> You should be able to verify the page has the no-store header via the page
> info dialog.

sorry for spam.  I was wrong, but there is probably something in developer tools to do that.
To see if the no-store header is present, you need to do the following:

Open the Developer Toolbox (Ctrl or Command+Shift+K)
Go to the Network tab
Reload the page under question
After the page has finished loading, click on the entry at the top of the list
A box on the right will appear
Look in the Headers section
Within Response headers, you should see if "Cache-Control: no-store" is present.

For example, facebook.com shows http://screencast.com/t/dGdkcV9k6C9v
User Agent : Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20130711 Firefox/24.0
Build ID : 20130711004005

Tested this on latest Aurora build using Facebook pages and other websites. For all, "Share" icon was working.

User Agent : Mozilla/5.0 (Windows NT 6.2; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Build ID : 20130708202947

Tested this on Firefox 23 B4 build using Facebook pages and other websites. For all, "Share" icon was working.
status-firefox23: fixed → verified
Thanks Samvedana, can you also test along the lines of what Jared has suggested in comment 15?
User Agent :Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20130712 Firefox/24.0
Build ID : 20130712004003 (Latest FX Aurora)

I see "Cache-Control: no-store" for first entry in the list for facebook.com

User Agent :Mozilla/5.0 (Windows NT 6.2; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Build ID : 20130711122148

I see "Cache-Control: no-store" for first entry in the list for facebook.com
Status: RESOLVED → VERIFIED
status-firefox24: fixed → verified

Updated

5 years ago
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.