New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tagsrvcs.com #431

Closed
massar opened this Issue Jun 18, 2015 · 24 comments

Comments

Projects
None yet
9 participants
@massar

massar commented Jun 18, 2015

http://s.tagsrvcs.com/2/4.9.4/loaded.js
http://s.tagsrvcs.com/2/825542/analytics.js

are loaded from:
http://assets.adobedtm.com/6372cf21ef88ee60bc2977a4898dcb5c7945a212/scripts/satellite-5579cf7562663803ed570200.js
http://assets.adobedtm.com/6372cf21ef88ee60bc2977a4898dcb5c7945a212/scripts/satellite-554bd4186631632069aa0300.js

Which then calls up on http://s.tagsrvcs.com/ to actually log stuff.

they log every 5 seconds what the heck you are doing on arstechnica.com
Seems arstechnica just needs to become a no-js site with the various trackers they are loading....

@cooperq

This comment has been minimized.

Contributor

cooperq commented Jun 18, 2015

@massar pardon me, but I'm not sure I understand what the bug you are reporting here is. Could you rephrase, perhaps?

@massar

This comment has been minimized.

massar commented Jun 18, 2015

Go to any arstechnica.com article, check the 'network' tab of Chrome and see that the above tracking stuff is being loaded.

@SwartzCr

This comment has been minimized.

Collaborator

SwartzCr commented Jun 18, 2015

in future versions of privacy badger you will have the ability to block third parties that aren't serving cookies. If you want to use the experimental version of privacy badger you can pull from the git repo now, otherwise we should have a new release out in a few weeks!

@SwartzCr SwartzCr closed this Jun 18, 2015

@massar

This comment has been minimized.

massar commented Jun 19, 2015

It would be good if there is a "Limitations" section in the readme that describes what PB does and what it does not block. Which could then also state 'X blocked starting at version N".

@SwartzCr

This comment has been minimized.

Collaborator

SwartzCr commented Jul 10, 2015

The issue privacy badger is trying to solve is data aggregation across multiple first party sites. It's not as important to use to block tracking across a single first party domain because that first party domain also clearly can track you. If Ars technica allows a third party that sees what you're doing on ars technica, this seems no different than ars collecting their own analytics, and presumably it is ars's choice. The issue comes when that same thrid party knows what you're doing on other first party domains, and that is what Privacy Badger blocks. This should all be explained in our (upcoming) expanded onboarding site

@massar

This comment has been minimized.

massar commented Jul 11, 2015

It's not as important to use to block tracking across a single first party domain because that first party domain also clearly can track you.

The site itself is always the one that decides to track you. Thus under that comment, PB will not disable tracking for anything.

For instance, everyone knows that a little Twitter "Tweet count" or a Facebook "Like" or a Google "Plus" icon on the site also causes tracking (due to referrer and cookies, and well a connection).

But would for instance:
8<--------
https://twitter.com/incloud/status/619624021123010560

"WebRTC being used now by embedded 3rd party on http://nytimes.com to report visitors' local IP addresses. "
-------->8

NYTimes clearly decided to add that to their site, thus enabling tracking of their users.

Be something that Privacy Badger will block? If not, then what is the point of PB?

@michael-oneill

This comment has been minimized.

michael-oneill commented Jul 11, 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As well as your local IP address being reported there is also a (browser created) persistent UID used by Media Capture & Streams (deviceId), which is also accessible third-party JavaScript in a drive-by attack.

https://lists.w3.org/Archives/Public/public-privacy/2015AprJun/0080.html

Also if a tracker controls the DNS Nameserver for a domain it can create a wildcard entry for a STUN server and track that way. See:

https://www.w3.org/wiki/Privacy/IPAddresses#Using_wildcard_DNS_entries_as_persistent_identifiers

Mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using gpg4o v3.4.103.5490 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJVoMS8AAoJEHMxUy4uXm2JxqoH/2m8UF1hNe2vRpE1jR1Tm32j
OMO8887EYXk0ro/K8JXC/FrlWgtxAtJVo9yhlCzBJb4Briwu4oYSt86nY5P7X21Z
KRjOM277kOB74eG3fcpzfJEkOhknMOF/K6COheSWQOq4YyahmJJC7UmAt2TixMLq
7DCLJme7eoDkbUPFSBbIfLssZLTvffr1lw0CzyzvtJrxyH5Z2l1wc3aOzUjXQOk8
XKyuGwwBGpwmIRocwoiZ5w9p4lhk7HnkPo5jGyEtsF50jILjZBHALH1Hfp1mo/Ae
eLi+AOej+70eq8Bt71NLD9BPKG0KUFZ1jNYN9ANC5ETN7lP+OBWgaoiDL+o77fA=
=rswT
-----END PGP SIGNATURE-----

@dakami

This comment has been minimized.

dakami commented Jul 11, 2015

This is part of an anti-bot technology I've been developing at White Ops (whiteops.com) for some time. There's a flip side to privacy here; turns out something like 2/3rds of bot fraud comes from home users who get compromised so as to effect more ad fraud. We're basically attacking the funding channel that gets people hacked. But it does require us to be able to detect the hacking, so we have these tests deployed.

We don't have any persistent IDs in our system; they don't actually help with bot detection because bots have all the IDs (which has been a problem for years).

@jwilkins

This comment has been minimized.

jwilkins commented Jul 11, 2015

@dakami Which part is whiteops? The WebRTC, the extra 12 requests/minute or both?

@dakami

This comment has been minimized.

dakami commented Jul 11, 2015

Both. We're getting some interesting things where we get embedded a pile
of times on a page and we're adapting the code to deal with that.

On Sat, Jul 11, 2015 at 4:14 PM, Jonathan Wilkins notifications@github.com
wrote:

@dakami https://github.com/dakami Which part is whiteops? The WebRTC,
the extra 12 requests/minute or both?


Reply to this email directly or view it on GitHub
#431 (comment)
.

@jwilkins

This comment has been minimized.

jwilkins commented Jul 11, 2015

@dakami you get how that's a dick move, right? Compromising user privacy and security in order to make ad view attribution better for companies.

@dakami

This comment has been minimized.

dakami commented Jul 12, 2015

Two thirds of ad fraud is coming from home users. All those ways home
users get hacked -- drive bys, app wrappers, codec packs, fake avs -- guess
what's paying for all these botnets.

We don't do anything to legit users -- not even a CAPTCHA. But we stop
checks from being written to people getting code execution on their boxes.
I think that's pretty cool.

On Sat, Jul 11, 2015 at 4:58 PM, Jonathan Wilkins notifications@github.com
wrote:

@dakami https://github.com/dakami you get how that's a dick move,
right? Compromising user privacy and security in order to make ad view
attribution better for companies.


Reply to this email directly or view it on GitHub
#431 (comment)
.

@jwilkins

This comment has been minimized.

jwilkins commented Jul 12, 2015

No doubt. But let me understand your argument, you are saying that you're going to wipe out botnets with invasive user enumeration and you're going to do it with features of the browser and nothing underhanded?

You don't think that they'll just improve their tools so that you can't detect them again? You know, the way that the cat and mouse game has gone the last couple of decades.

@dakami

This comment has been minimized.

dakami commented Jul 12, 2015

No absolutes in this game, you know that painfully well. But we can (and
are) certainly biasing ourselves towards busting bots and away from
violating user privacy. The bots actually have all the user PII, so it
doesn't inform us at all if it's present or absent. It's one of many
reasons we don't even use persistent storage/cookies.

On Sat, Jul 11, 2015 at 7:56 PM, Jonathan Wilkins notifications@github.com
wrote:

No doubt. But let me understand your argument, you are saying that you're
going to wipe out botnets with invasive user enumeration and you're going
to do it with features of the browser and nothing underhanded?

You don't think that they'll just improve their tools so that you can't
detect them again? You know, the way that the cat and mouse game has gone
the last couple of decades.


Reply to this email directly or view it on GitHub
#431 (comment)
.

@jwilkins

This comment has been minimized.

jwilkins commented Jul 13, 2015

Away from violating user privacy? You're polling 12x a minute and leaking the user's IP. It doesn't matter that you're not also hoovering their assorted cookies and so forth, you are assisting the services that do create them. If your product works, you are making increasing the accuracy of the tracking and making it cheaper to collect this data. Not just for advertisers, but for the intelligence community which we know piggybacks off this type of thing.

If you presume that the box is compromised and a rootkit is more than possible, you're in the position of trying to identify malicious behavior from a constrained sandbox in the browser. You are trading off user privacy for a battle that you will lose as soon as your product gets enough traction to affect the botnet owners.

Dan, I hope that this is just a case of tunnel vision and that you'll step back and take a look at what you're building.

@jacobsoo

This comment has been minimized.

jacobsoo commented Jul 13, 2015

Seems like washingtonpost.com, nbcnews.com, ft.com , cnbc.com & bloomberg.com all uses the same 3rd party tracking code from s.tagsrvcs.com too. O.o"

@jacobsoo

This comment has been minimized.

jacobsoo commented Jul 13, 2015

Seems like mostly American website(s) are using that.
http://www.vanityfair.com/ and http://www.wired.com/ are using the same3rd party tracking code.

Apparently Eric Lawrence found an interesting thing if the content is blocked in IE.
http://textslashplain.com/2015/06/22/content-blocking-unintended-consequences/

@michael-oneill

This comment has been minimized.

michael-oneill commented Jul 14, 2015

@dakami

This comment has been minimized.

dakami commented Jul 14, 2015

Indeed, I killed the STUN queries.

--Dan

On Tue, Jul 14, 2015 at 12:19 PM, michael-oneill notifications@github.com
wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jacob,

That was quick.

As of about an hour ago there are no longer STUN accesses from nytimes.com,
washingtonpst.com, ft.com and cnbc.com. In case it is a geolocation
specific thing what are you seeing? I am in UK

Mike

From: Jacob Soo [mailto:notifications@github.com]
Sent: 13 July 2015 15:55
To: EFForg/privacybadgerchrome
Cc: michael-oneill
Subject: Re: [privacybadgerchrome] tagsrvcs.com (#431)

Seems like mostly American website(s) are using that.
http://www.vanityfair.com/ and http://www.wired.com/ are using the
same3rd party tracking code.
Apparently Eric Lawrence found an interesting thing if the content is
blocked in IE.

http://textslashplain.com/2015/06/22/content-blocking-unintended-consequences/

Reply to this email directly or view it on GitHub./
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using gpg4o v3.4.103.5490 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJVpWCpAAoJEHMxUy4uXm2JNVUIANavZ8w24KpLpKAP1Aopacw7
mQnDyaFuCN/zzZWBPxLuDa0mV8x9b463QiLBc59hqFBtsCuhUhTJ0btxpVaDcf9g
1i5mRv2HMWoIsdGjVJX16+3KlE2vv+PQ+jSMIhVVcMYXqiQ7KdmDBVb8CBhStOPy
MOjTbMyZx2WGK3DSvj77X74NkKv+1uR54Y3bMPX+yc3ztX5cb/deqorUbyt3b7/U
KfW1QgwsTvjMdooaq/QFHwAW9XGUOXA1GcFuufZL1AmfCFAUiq8sF2O7VAce+Wem
7jS2HB8Ym0h7G9+9XrZDfRSSBHDQaPnT5tG2m1jZfvD3q8WjH5sAXZqpx5noOZc=
=J6Ct
-----END PGP SIGNATURE-----


Reply to this email directly or view it on GitHub
#431 (comment)
.

@jwilkins

This comment has been minimized.

jwilkins commented Jul 15, 2015

@dakami Thank you, great start! If you ever want a fresh set of eyes on this sort of thing, ping me, we can debate it over coffee/drinks.

@jacobsoo

This comment has been minimized.

jacobsoo commented Jul 15, 2015

Indeed that previous WebRTC script is removed. Now they are using another script for tracking though.
Haven't look whether PrivacyBadger will work well against that though.

The script is seen at http://bloomberg.com
http://pastebin.com/KV1YBDrp

@dakami

This comment has been minimized.

dakami commented Jul 15, 2015

"They" is me! Happy to jump on a call and discuss.

On Tuesday, July 14, 2015, Jacob Soo notifications@github.com wrote:

Indeed that previous WebRTC script is removed. Now they are using another
script for tracking though.
Haven't look whether PrivacyBadger will work well against that though.

The script is seen at http://bloomberg.com
http://pastebin.com/KV1YBDrp


Reply to this email directly or view it on GitHub
#431 (comment)
.

@michael-oneill

This comment has been minimized.

michael-oneill commented Jul 15, 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for your fast response Dan. The previous code has illuminated important privacy risks with this otherwise useful API.

Mike

From: dakami [mailto:notifications@github.com]
Sent: 14 July 2015 20:53
To: EFForg/privacybadgerchrome
Cc: michael-oneill
Subject: Re: [privacybadgerchrome] tagsrvcs.com (#431)

Indeed, I killed the STUN queries.

  • --Dan

On Tue, Jul 14, 2015 at 12:19 PM, michael-oneill notifications@github.com
wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jacob,

That was quick.

As of about an hour ago there are no longer STUN accesses from nytimes.com,
washingtonpst.com, ft.com and cnbc.com. In case it is a geolocation
specific thing what are you seeing? I am in UK

Mike

From: Jacob Soo [mailto:notifications@github.com]
Sent: 13 July 2015 15:55
To: EFForg/privacybadgerchrome
Cc: michael-oneill
Subject: Re: [privacybadgerchrome] tagsrvcs.com (#431)

Seems like mostly American website(s) are using that.
http://www.vanityfair.com/ and http://www.wired.com/ are using the
same3rd party tracking code.
Apparently Eric Lawrence found an interesting thing if the content is
blocked in IE.

http://textslashplain.com/2015/06/22/content-blocking-unintended-consequences/

Reply to this email directly or view it on GitHub./
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using gpg4o v3.4.103.5490 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJVpWCpAAoJEHMxUy4uXm2JNVUIANavZ8w24KpLpKAP1Aopacw7
mQnDyaFuCN/zzZWBPxLuDa0mV8x9b463QiLBc59hqFBtsCuhUhTJ0btxpVaDcf9g
1i5mRv2HMWoIsdGjVJX16+3KlE2vv+PQ+jSMIhVVcMYXqiQ7KdmDBVb8CBhStOPy
MOjTbMyZx2WGK3DSvj77X74NkKv+1uR54Y3bMPX+yc3ztX5cb/deqorUbyt3b7/U
KfW1QgwsTvjMdooaq/QFHwAW9XGUOXA1GcFuufZL1AmfCFAUiq8sF2O7VAce+Wem
7jS2HB8Ym0h7G9+9XrZDfRSSBHDQaPnT5tG2m1jZfvD3q8WjH5sAXZqpx5noOZc=
=J6Ct
-----END PGP SIGNATURE-----


Reply to this email directly or view it on GitHub
#431 (comment)
.


Reply to this email directly or view it on GitHub./
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using gpg4o v3.4.103.5490 - http://www.gpg4o.com/
Charset: utf-8

iQEcBAEBAgAGBQJVpkDCAAoJEHMxUy4uXm2J1JsH/j9J77JybByee4jPLZySdlTN
OIlqUU+V95XrzSShXtuLL682oF0xTYdY2n56lMMQw4LQ66FXIdjE10Ptj9yE8XUU
pVdhDpSPub2O68azb9KgJGwWCHqbQRTBc+Gc6J+bCgjVq3HNPnTvaAzQXRFwm/rf
HrTgCKFfjFcKdbWyRBJomA93qouQyr3y7BMXclzOt4rJXRNcoDHMy/Mpef12PLtU
ToIy3BPB9Wgnz8SDeJxGcsqiPkj4JydaF8ik7hYcMjxamBC13YIfQxuJsz2bzSwz
GIFKOl2jHCcwAzkP+De3Z5VYblHmi4LnDqnwkUd7mIOQodQ9xwzhsysf/qlr1sE=
=j59j
-----END PGP SIGNATURE-----

@Ammond

This comment has been minimized.

Ammond commented Jul 31, 2015

(Dakami) Dan,

The functionality used by s.tagsrvcs.com causes transparent authentication to fail. This affects all entities, especially enterprises that use transparent authentication. The simple fix is to set s.tagsrvcs.com to NOT authenticate or use explicit auth.

Can the code be written to work well with transparent auth? In that mode redirection is used to get auth. Browsers pop-up a auth panel to enter credentials for s.tagsrvcs.com. Users think their workstations have been compromised.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment