Option to remove metadata from URL

[intchloe]

Read more: https://medium.com/@jeremyrubin/caution-copy-pasting-urls-from-google-search-can-leak-previous-searches-11940508e79

Some URLs have metadata in them and when sharing them they can leak sensitive data. 3 exemples:

1. https://www.google.se/search?q=%221%22&gws_rd=cr&ei=d4VDVtTeOeK_ygOcgoioCQ#safe=off&q=%222%22
2. http://www.imdb.com/name/nm0147147/?ref_=nv_sr_1
3. https://www.youtube.com/watch?v=mHSaHRd4Q48&feature=youtu.be

If you search from the address bar in Chrome and then search again on Google your old search is still in the URL as metadata!

Imdb also have metadata, in my example I searched(nv_sr = navigate searchbar)

If you click on a youtu.be-link the full link will tell you so(&feature=youtu.be)

There are more examples of course. I think this would be a great feature in Privacy Badger. The best option would be to rewrite the URL even before you visit it because then would none see the metadata, not the server, someone behind you nor the person you're sharing the link to.

Regards,
Chloe

[KidPluto]

I understand the issue, but don't understand the enhancement request. Are you proposing that PB have the ability to change the URL before it is sent? What does that have to do with trackers? Are additional trackers the result of this type of URL? Thanks.

[ghostwords]

Related: #85

[njourdane]

Up, I'm really interested by this. :)

I personally use au-revoir-utm to remove utm data and it works pretty well, but I'm interested by having only one privacy add-on.

I found recent merge-requests about anti link-tracking, like #2016, but AFAIU this doesn't remove utm data.

[bcyphers]

I think stripping UTM parameters in particular would be an easy win. They're widely used, and afaik exclusively used for tracking. @roipoussiere if you're interested in working on a PR for this feature, I'll review it. Otherwise I'll get to it after catching up on some other backlogged stuff.

[bcyphers]

I want to start working on this, building off au-revoir-utm, but we'll have to watch out for conflicts with HTTPS Everywhere and other url-rewriting extensions (jparise/chrome-utm-stripper#13).

This is a problem with browsers in general; webextensions should really allow multiple extensions to rewrite the same URL in sequence. Since they don't, we need to work around the conflicts, especially since there's a lot of overlap between ours and HTTPSE's users. We have a few options:

1. Short-term: only rewrite requests that are already https. This should avoid almost all dangerous conflicts with HTTPSE (thanks, @ghostwords).

2. Mid-term: Rewrite static links on web pages using techniques like Add basic link-tracking protections to Google sites, update Facebook content script, and factor out common code. #2016. This will avoid the conflicts altogether, but might add significant performance overhead to some sites and won't catch all requests.

3. Long-term: merge EFF's two browser extensions into one! I can't imagine there are a lot of PB users who would opt-out of having HTTPSE functionality built in. The other way around might be different, but we can make it easy for users to opt out of Privacy Badger's blocking if they want to. Having a single code base would allow us to avoid issues like these, and avoid duplicating problems like Excuse me if this isnt the appropriate place to ask this, but I would like to know why the plugin needs new FF permission: access to all data of any website https-everywhere#16377. I'll be opening a separate issue for this so we can discuss it more.