freelawproject / recap

This repository is for filing issues on any RECAP-related effort.
https://free.law/recap/
12 stars 4 forks source link

RECAP is detectable in Chrome via image sniffing #253

Closed mlissner closed 1 year ago

mlissner commented 6 years ago

Over in https://github.com/freelawproject/courtlistener/issues/852, @Pascal666 made a POC that can detect if you've got PACER installed. It sniffs for images in the extension and works in Chrome.

Some websites operators have in the past asked for us to make RECAP detectable in this way. I don't think anybody currently uses this loophole though, so this is a privacy issue that we should resolve.

We could probably fix this by inlining the images in the extension.

Pascal666 commented 6 years ago

Perhaps convert most/all of the PNGs to SVGs at the same time. That way one image can be scaled to whatever size is needed, rather than storing various sizes of the same image, and inline SVG is much smaller and doesn't need BASE64 encoding. Do the relevant images already exist somewhere as SVGs?

johnhawkinson commented 6 years ago

I think its probably worth a query to the Chrome developers. It sounds like this has been an outstanding problem for several years and at the very least they deserve a push on it. Although inlining is a workable solution, it doesn't seem like the Right one.

I realize I may be sounding inconsistent here. Sorry.

Pascal666 commented 6 years ago

Looks like extensions can be detected by ID even if they don't expose images: https://www.ghacks.net/2017/08/29/browsers-leak-installed-extensions-to-sites/

Keep in mind that none of the above solutions will have any effect on PACER's ability to detect RECAP. Off the top of my head:

When someone requests a document, docket, etc. PACER could use the RECAP API to see if it has already been uploaded, serve the data to the user, and if it didn't exist before, check the API again to see if it exists now.

Or add javascript to the page triggered by DOM changes that notifies them when RECAP adds information to the page.

mlissner commented 6 years ago

I don't see them using an API, but I could see them doing the JS thing if they cared. Maybe we're over promising here and the best solution is to keep our system simple and update our FAQ about this. These are good points. Also, it's been almost ten years and we don't think they've ever tried to detect RECAP. That's probably the more important factoid.

johnhawkinson commented 6 years ago

I don't see them using an API, but I could see them doing the JS thing if they cared

I agree only partially, but was encouraged to offer a Comment, so here we go:

I do not think that the AOUSC is going to use active measures to detect or thwart RECAP or other extensions. That strikes me as incredibly unlikely, and I do not think they will do JS probing, and think there would be appropriate public outcry if they manifested JavaScript that did that. With respect to the AOUSC, I'm concerned with passive detection measures they could determine through log analysis or other such things, such as the example discussed in https://github.com/freelawproject/courtlistener/issues/852#issuecomment-404360575.

I do think we should worry about other actors detecting the extension (non-AOUSC), and that other extension developers and browser developers have good reason to be worried about this and we can expect them to adopt measures to limit exposure (although it seems quite slow going! 4 +years?). We should make sure to adopt whatever browser API techniques to avoid extension fingerprinting if/when those become available. I do not think this is a particularly pressing or timely concern.

mlissner commented 1 year ago

Another four years and this hasn't come up at all since. I think it's safe to say it's not a big enough issue to warrant a fix, since the fix is small/medium in size, and nobody cares about the issue over a many-year timeline.