
Twitter Direct Message Caching and Firefox - feross
https://hacks.mozilla.org/2020/04/twitter-direct-message-caching-and-firefox/
======
faitswulff
So basically Twitter wasn't setting its Cache-Control directive correctly? Why
is this behavior different from Safari and Chrome?

It looks like "no-store" is in this IETF RFC:
[https://tools.ietf.org/html/rfc7234#section-5.2.2](https://tools.ietf.org/html/rfc7234#section-5.2.2)

EDIT - Ah, I see, it's in the original post:

> Testing from Twitter showed that the request was not being cached in other
> browsers. This is because some other browsers disable heuristic caching if
> an unrelated HTTP header, Content-Disposition, is present. Content-
> Disposition is a feature that allows sites to identify content for download
> and to suggest a name for the file to save that content to.

> In comparison, Firefox legitimately treats Content-Disposition as unrelated
> and so does not disable heuristic caching when it is present.

It looks like Twitter only tested this in Safari and Chrome and called it a
day. Their wording implies that it's Firefox's fault, which is misleading.

~~~
badrabbit
I have fuming anger over the whole world deciding Google will set the standard
for browsers. I wonder if EFF and similar orgs are doing anything legally,
perhaps EU can armtwist again?

~~~
oefrha
[https://tools.ietf.org/html/rfc7234#section-4.2.2](https://tools.ietf.org/html/rfc7234#section-4.2.2)

    
    
       Since origin servers do not always provide explicit expiration times,
       a cache MAY assign a heuristic expiration time when an explicit time
       is not specified, employing algorithms that use other header field
       values (such as the Last-Modified time) to estimate a plausible
       expiration time.  This specification does not provide specific
       algorithms, but does impose worst-case constraints on their results.
    

The standard does _not_ say what heuristics should be used, so Firefox’s
heuristics is no more “legitimate” than Chorme/Safari’s heuristics of expiring
immediately when Content-Dispostion is present.

“Firefox legitimately treats...” is highly misleading, making it sound like
Firefox is more standard-compliant, but it’s not; it’s just different.

~~~
notRobot
Please don't use code blocks for quotes. It makes it very hard to read text on
mobile, narrow viewports or via screen readers.

~~~
oefrha
RFCs are published as plain text with line breaks, which I literally copied
without even changing the indentation, so barking up the wrong tree here.

~~~
notRobot
I'm not. If copied without formatting as code blocks, the text would be a lot
more readable and wouldn't require horizontal scrolling on narrow viewports.

------
felipc
The thing that boggles my mind is that the only affected users are:

(a) - Firefox users &&

(b) - who downloaded their messaging history on a buried menu option in the
account page &&

(c) - in the last 7 days prior to disclosure &&

(d) - who did this on a computer where someone else has access

The number of affected people is presumably very small, and the only metric
that twitter can't know here is (d). How on earth does it make sense to alert
every Firefox user with a scary wall of text? Don't they have logs to cross-
reference (a), (b) and (c) and e-mail these users?

I'd believe that if there's only one API endpoint that would be crucial to log
to protect against major leaks, it would be this one to download all your
history at once...

~~~
detaro
re (b) Twitter says "took actions like downloading your Twitter data archive
or sending or receiving media via Direct Message,", so it isn't just
downloading the archive, and to me "actions like" suggests there might be more
than the ones named here explicitly. And they might not be able to tell who
did it for all these things.

I also didn't see any notice, but I don't know if I missed it, my adblocker
ate it, or if they actually did only inform users that did one of the at-risk
things and I happened to not do so.

------
riquito
Lovely how Twitter's blog post does nothing to explain is not Firefox fault.

~~~
eps
You don't say.

Pasting an URL into a tweet entry form in their web client has been resulting
in "Something went wrong" in 50% of cases for several months now. Attaching a
GIF to a tweet randomly fails with no explanation given, again - for months.

I don't know what Twitter's development priorities are, but they sure as hell
don't include proper web client testing.

~~~
jakub_g
Never got any of those. Perhaps you're using slow/unreliable network and
hitting timeouts? Or some privacy tools interfering? Using Firefox web
Twitter.

One thing I did use to repro though was text field behaving erratically on
Firefox Mobile or when using installed PWA from home screen. Had to give up
and use Chrome directly.

------
JBReefer
Mozilla Hacks continues to be the best webdev blog

------
gav
Why would Twitter send a Content-Disposition header with their API responses?

    
    
        content-disposition: attachment; filename=json.json

~~~
r1ch
I believe this is for additional XSS protection - if a user clicks a
suspicious API link, the worst that happens is the browser downloads a
json.json file instead of rendering a potentially malicious payload.

~~~
anamexis
How would rendering the file perform a malicious action?

~~~
chias
If the content-type header failed to get sent, or if a browser (lookin' at
you, IE) chooses to ignore it in favor of what it thinks it probably should
have been, then the result can get rendered as HTML. If you have some json
that has angle-brackets in it (which, being JSON, would obviously not be HTML-
escaped) and the result is rendered as HTML, this can result in your browser
executing attacker-defined javascript in Twitter's origin.

Sending it as a "file download" has no effect on what happens when the
endpoint is called via AJAX, but in the event that a browser navigates to it
directly, ensures that even the dumbest of browsers do not render it as HTML.

------
re
A small amount of discussion on the previous post from the Twitter Privacy
team:
[https://news.ycombinator.com/item?id=22762467](https://news.ycombinator.com/item?id=22762467)

------
SimeVidas
No mention of Clear-Site-Data?

[https://w3c.github.io/webappsec-clear-site-data/#example-
sig...](https://w3c.github.io/webappsec-clear-site-data/#example-signout)

------
ludwigvan
I think a similar issue exists with Twitter and Safari. (Maybe related to web
worker or page caching) Sometimes I need to restart Safari, otherwise Twitter
fails to load. When I type twitter.com, the site occasionally hangs in that
browser. Just putting this to see if some others are effected.

------
jsjddbbwj
Expect to see more of these as fewer and fewer people use Firefox and web
developers simply don't try their websites on this browser. And as more
websites stop working correctly on Firefox, they will lose more market share.
Some kind of spiral, you know?

I was thinking that a rendering bug (which is what one expects from a browser
compatibility bug) is not that bad, but when we are talking privacy and
security, now that's a problem.

------
the_mitsuhiko
Clearly a bug on Twitter's side but the behavior to disable caching when
content-disposition is used seems sensible.

~~~
JBReefer
Why? It’s not in the spec, how am I, the developer, supposed to know that the
browser is being non-compliant?

~~~
detaro
It's in the spec that the browser is allowed to pick a duration if you don't
tell it one, so you know that you don't know how long it is cached if you do
not set a header.

[https://news.ycombinator.com/item?id=22775479](https://news.ycombinator.com/item?id=22775479)

