Podcast: Play in new window | Download

Many websites these days have to deal with the reality of incorporating third-party scripts. These could be tracking scripts or analytics or monitoring, or even scripts that add explicit features to a site, such as chat. Regardless of the purpose, such scripts add complexity and overhead, and can interfere with the proper operation of the site. In this episode Ben Vinegar, VP of engineering at Sentry, joins the panel to discuss the complexities and implications of third-party scripts, both from the perspective of website developers, as well as from the perspective of the developers creating such scripts.

Sponsors

Panel

Special Guest

Links

Picks

Aimee

AJ

Charles Max Wood

Ben Vinegar

Follow JavaScript Jabber on Twitter: @JSJabber

Special Guest: Ben Vinegar.

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel we have Amy Knight.

AIMEE_KNIGHT: Hey hey from Nashville. 

CHARLES MAX_WOOD: Dan Shapir. 

DAN_SHAPPIR: Hi from Tel Aviv, where the only good thing I can say about the weather is that it's great that we all have air conditioning. 

CHARLES MAX_WOOD: AJ O'Neill. I'm Charles Max Wood from Dev Chat.tv. Just want to encourage you to go check out mostvaluable.dev. And we have a special guest this week, and that's Ben Vinegar. Hi, Ben. Ben, do you want to introduce yourself? 

BEN_VINEGAR: Yeah, sure. My name's Ben. I'm the VP of engineering at Sentry, which is a product that helps software developers sort of like find errors and performance problems with their production software. I'm also the author of a book, co-author book called Third Party JavaScript that was published with Manning publications in 2013. 

CHARLES MAX_WOOD: Oh nice. 

 

Hey folks, one of the things that I find that really makes a difference from people being happy in their job is working in a place that makes a difference. And there's a terrific company out there that's looking to hire full stack developer just like you. And that's Faithlife. Their average tenure is five years. I mean, five years, that's forever in developer years. Usually I see people changing jobs every one to two years. People are sticking around because they're great. They have a great values-based culture and they are hiring developers in the United States. They're looking for full stack developers who can do C-sharp or JavaScript on the backend and React on the front end. Go check them out at devchat.tv slash faithlife. That's devchat.tv slash faithlife. 

 

CHARLES MAX_WOOD: Yeah, we're gonna be talking about third party JavaScript. Do you wanna just kind of give us an idea? Cause I had like three different things go through my head when I initially saw third party JavaScript, you know, before we discussed what it was and how it kind of comes into play here. So when you're talking about third party JavaScript, what are you talking about?

BEN_VINEGAR: So when I wrote this book, I think I dedicated the first chapter to just like, what is this? The way that I describe it is, you know, if you, if you think about two parties exchanging and like a website exchange, right? Like I'm a user, I use my web browser and I access a website and from that website, from that web server, you can think of them as the second party and they're serving you, you know, resources, scripts, HTML to render an experience. But then you also have third parties, right? You have sort of almost like hangers on that can be a script tag that links out to another web server that returns content that does some other added behavior. Often that's probably the most, the version that everybody's familiar with that everybody's running is like Google analytics. So you can think of his third party JavaScript. If you're running a content website and you earn revenue via ads, right. Ad scripts are also another version to inject an ad, do some basic tracking. There's also, you can think of, you know, there's more elaborate versions of that. Part of the reason I wrote this book is I worked at a company called Disqus, which is still kicking around. That's D I S Q U S. 

CHARLES MAX_WOOD: And they use that for comments on dev chat, not TV. 

BEN_VINEGAR: Yeah. And they embed effectively like an entire application, right? So you put in a script tag and you get an embedded commenting application and that's all being served via third party JavaScript. So, oh, and then maybe the last version I would highlight is you can argue that browser plugins that use JavaScript are also a version of third-party JavaScript, right? When you install a plugin and it says, hey, this script can access your web content, you're kind of granting another party access to the exchange that's taking place. And it uses JavaScript to sort of inject experiences into your browsing session. 

DAN_SHAPPIR: So I have two questions about this, kind of like make the definition even more precise. If I'm using JavaScript in my web application, let's say an open source library like Lodash, but I'm actually hosting it on my own server rather than bringing it, I don't know, from Cloudflare or something like that. Would that count as second party, first party, third party? How would you count that? 

BEN_VINEGAR: So I don't usually include that in the definition for a couple of reasons. Because one, if you as the website or the web server publisher, for simplicity, I just call them publishers. If you're providing that content, it's coming from your servers, it's being served alongside your code, maybe if you use Webpack, it's been bundled into your code. So it's all being, you know, it's all intermingled, right. And there's no access of a third-party server. And I think that that is, I think that's the definition that most of us kind of align with if you Google third party JavaScript and you see, you know, articles on this topic from developer advocates from Google, you know, they're often concerned about third party JavaScript as potentially impacting the performance of website, which is a real concern. And you don't have that concern if you're, if you completely sort of serve that content yourself and you have full control, does that make sense? 

DAN_SHAPPIR: Yes, it does. Although the lines can get blurry, I think, because for example, I work at Wix and at Wix we actually have our own like quote unquote third party domains. So all a Wix site would have the domain that its owner purchased for it, but then we would serve JavaScript, let's say to that site from our own domain. So since that site is also hosted on Wix, would that count as third party or not? You know, it's...The definition can get a little bit blurry here. 

BEN_VINEGAR: From some of the, like from some of the technology involved, serving it from another, you know, web server address definitely means that you have to deal with all of the concepts around third-party JavaScript, but I, in my mind, what you're mostly concerned about, you know, when I think about third-party JavaScript is there is literally another, another organization that's behind this. For example, if you are hosting your own code, you know, you have control over that. But if you're linking out to a snippet from Google Analytics or some other third-party JavaScript, you really have no idea what they could be injecting into your website. And the reverse is also true when you are a third-party provider of JavaScript, you know, you're injecting code into a sort of unknown environment. You actually don't know what's on the other side. Right. So, and this goes for browser plugins too, in the sense that, you know, browser plugins can auto-update. You don't really know what content you're injecting into your page and that can provide complications that you have to be mindful of. Does that make sense? 

DAN_SHAPPIR: Yes, it does. 

CHARLES MAX_WOOD: What comes off of Dan's example though, is that if I own the Wix website and I, or they are injecting their code into my website, then I guess I could kind of see it as third-party software to me, even though they mostly control the environment and everything around it because it's a Wix page. And so I think some of this just is down to your point of view as well. 

AJ: Yeah. In that case, I would consider the user's JavaScript to be third-party because that's what has potential negative security risk for Wix. I mean, when I think third-party, I think third-party is what is the security risk? And in this case, the security risk is the user. Because Wix is not going to create a security problem for the user. The user might create a security problem for Wix. 

DAN_SHAPPIR: That's an actually valid point. And yeah, we do need to deal with that. 

BEN_VINEGAR: You know, I also want to paint, I don't want to look at their project script as being a security vector. Although there's truth to that. It's also even, it's broader than that. Like the scripts that they inject might interfere with the way that you render the page. They might occupy the UI thread so that the rendering of the experience that you want as the sort of like publisher is impacted by those scripts in a way that you may have very little control over, right? Because they're just sort of injected to the page and you may not be able to control the flow of how that application executes. 

AJ: Well, to use the modern political parlance then, who's the most vulnerable party? The other one is the third party. 

DAN_SHAPPIR: Yeah. But like Ben said, vulnerability is only just a part of it. It's the mere fact that you're seeding control. And the fact that once the JavaScript is running in the browser session, it's got as much rights to do stuff as like quote unquote first-party JavaScript. It can do anything that your JavaScript can do. And then they share the environment in fact. And from the user's perspective, the visitor's perspective or the user perspective, he's certain that..They certainly don't tell them apart. So yeah, the applications can be significant and not just security. 

CHARLES MAX_WOOD: Well, one other thing, I've seen this in a couple of different ways with modern JavaScript, but back in the day, we'd have issues where you would load third party systems that use jQuery and then you also were using jQuery. And the third-party system you were bringing in used a different version of jQuery than the one that you loaded onto the website. And so you would run into collision issues with the APIs, even though, you know, theoretically they should just both work. And I've seen this again nowadays with, you know, for example, you'll, you'll have a website that for whatever reason, you know, loads in two different versions of a JavaScript framework or some underlying library and run in similar issues. And so, you know, third parties can, it can cause other issues. As Dan said, beyond just the security implications of, Hey, it's got full access and it might make an Ajax call down to somebody else that I don't want it talking to.

AJ: In this case by vulnerable and all senses of the word. So like if it changes the way your page looks That makes you vulnerable, you know, like if it if it does anything that tampers with the integrity of your site causing a poor user experience causing load times, you know all of that I would say, you know, even though often we use the words like integrity and vulnerability in the realm of security I would say I meant it in a broader sense. 

CHARLES MAX_WOOD: That's fair. 

BEN_VINEGAR: You can imagine why I say this I was gonna say you can imagine why I spent like a whole chapter trying to like be really clear about at least how the book interprets this. And I think Chuck, it's, it's kind of what you said, which is, yeah, it's where you're seeding control and maybe to bring it full circle. Like if you're embedding a library and bundling it and serving it from your content, I wouldn't consider that third party JavaScript. But if you are linking directly to a CDN that you don't control and who knows, for all you know, I mean, at least in the past, like they can just serve you whatever you wanted, whereas today you can have integrity checks to make sure that your expectation of the content is what you set out to load, right? As an example of how even this technology has evolve and AJ: unless you know what you're doing, CDNs are going to make your site slow. Like unless you're actually paying for a CDN and you're using it consistently for all your resources and actually following the caching and regional guidelines, you're just making your site slow and less reliable. 

DAN_SHAPPIR: It's interesting because the behavior of browsers has changed in a way that kind of impacts that it used to be that browser cache was shared between domains. So if I had a website and you had a website and we were both using, let's say jQuery and we were both using the same version from Cloudflare, then the fact that a person with their browser accessed your site would then benefit me if that same person accessed my site because jQuery could be delivered from the local browser cache. This is no longer the case. 

AJ: And it was never really the case because it would always make a request. So because... 

DAN_SHAPPIR: Well, not necessarily. If the cache duration was specified appropriately, it might not. 

AJ: Right. If it was specified appropriately, which generally they wouldn't, because doing that on a free service increases your support request rate, because people don't know how caches work, and they don't build their assets with like cash tag or whatever, they've got their web server set up incorrectly, all these things go wrong. And so then you get people doing all these support tickets to the CDN that are on free accounts, that are just burning time, because they're having trouble with caching and they don't know how to solve it.

DAN_SHAPPIR: Yeah, in any event, it's not really relevant anymore because for the listeners who may not know this, Safari, Firefox, and I'm not sure if Chrome is quite there yet or not, but if not, they're going to be there soon or use what is known as double keyed cache, which means that resources are not just cached by the URL, they're also cached by the main domain. So even if you do download the same site from the same URL from two separate sites, they won't share the cashe. So the resource would actually download twice. T

AJ: hat sounds like such a stupid idea, Dan. Why ever would that be? 

DAN_SHAPPIR: It's actually for privacy concerns to avoid breadcrumbs or tracing. Like suppose that I wanted to know that you it's interesting for, I want to track users. I could actually have resources like downloaded from common URLs across my, my gamut of websites, and then by checking the delivery times and the download sizes, I can actually figure out if a certain resource was delivered from the local cash or not. And then I can use that to kind of track you across, you know, which websites you visited. 

AJ: So these are known as e-tag cookies. 

DAN_SHAPPIR: No, this has nothing to do with e-tags. 

AJ: Oh, okay. 

DAN_SHAPPIR: This has to do with the fact that suppose you're downloading resource, you're using resource A dot JS from Cloudflare. And then my website also down uses a.js from Cloudflare, the same version with exact same URL. I can check with the browser to see how quickly downloaded or even how many bytes were downloaded, figure out that it was served from the local cache, and say, oh, OK, now I know that they visited AJ's website.

AJ: Oh, okay. So that's even like, that's even more subtle than e-tag cookies, but e-tag cookies, you get specific user tracking just the same as the way you'd get with normal cookies. That's what it is. Anyway, rabbit hole. 

CHARLES MAX_WOOD: I think, yeah, I was going to say, yeah, we've rabbit hold and yeah. 

BEN_VINEGAR: I think that this is an incendiary topic. I think that, you know, when I wrote this book, it is from the perspective of somebody developing products like this that have to also deal with the fact that, you know, third party scripts, I guess, have a pretty bad rap, iframes had a really bad rap for a long time, but the reality is that. You know, this is almost like a business relationship or these scripts are conferring value, right? Mentioned earlier, right? The podcast itself uses discussed comments, like it's getting something out of that. And so we're always going to have this. We're always going to have scripts that provide analytics and so forth. For example, even century monitors for errors is we have a script that lets you do this. So the question is, if you are developing that content. How do you be a good actor in the ecosystem? How do you develop an application that plays nicely with the host webpage, doesn't take advantage, or doesn't mess with the host page and make sure that doesn't interrupt rendering, make sure that doesn't lock the thread and so forth, right? So it's true, there's a lot of bad, I don't know if bad actress is the right word or third party scripts that can result in a negative experience, but there's also like plenty of products out there that do a lot of good value. And as long as they play nicely, like set good cash rules, then you can have a good experience and everybody's okay.

AIMEE_KNIGHT: One question I have, so we've talked about third party scripts being, you know, things that, that are outside of my control, but what about, well, outside of my code basis control or outside my code base, but what about third party scripts in the sense of, there are different things that, like, there are a lot of different marketing integrations that the developers may not be even aware of where I just, as a marketer go to some website give it, you know, whatever information it needs. And suddenly there's like script tags on the page. 

BEN_VINEGAR: Those qualify. 

AIMEE_KNIGHT: Yeah. Or even the case of like Google tag manager, you can have like your Google tag manager tag and just by nature of having that, you can hook in all kinds of scripts. 

BEN_VINEGAR: Yeah, absolutely. 

AIMEE_KNIGHT: Again, again, like outside of the control of like the developer. 

BEN_VINEGAR: Okay. Yeah. I think segment does this too, as tag managers. I think they all apply, right? 

AIMEE_KNIGHT: Yep. 

BEN_VINEGAR: And so they're, they're super common.Maybe in marketing, you know, marketing websites, especially. Yeah. I think they all qualify. I, it's a, it's a bigger industry and it's a bigger sort of like development space than sometimes we think about. 

DAN_SHAPPIR: Maybe it might be worthwhile for some of our listeners to explain exactly what Tag Manager is. 

AIMEE_KNIGHT: Yeah. So I, I know, man, it's been a while, so I don't completely remember, but my understanding Google Tag Manager is a way, you know what? I would have to look, actually. I don't completely remember and I don't want to give a wrong answer, but.

BEN_VINEGAR: I've used it very briefly. I think it's kind of, it literally manages like script tags that are injected into your marketing website so that, you know, non-developers can have some control or some flexibility over the configuration or on what pages things get injected and how, and so, you know, they don't have to go and call up the software team to go and make some minor script adjustments here or there. 

AIMEE_KNIGHT: Yeah, you're right. It's literally anything.

DAN_SHAPPIR: Yeah, you're basically giving Google the ability to inject anything into your website and presumably they do it based on what your marketing team decides to inject into your website and hopefully they only injects the stuff that actually needs to be injected and not other things. 

AIMEE_KNIGHT: The part I do remember about it probably is more like the programming side where you have something called like a data layer that sits, that that's how the code base talks to Tag Manager and passes like variables back and forth. 

DAN_SHAPPIR: The bottom line though, from my perspective, is I see a lot of websites that download huge amounts of resources or content or stuff from Google, from Facebook, from others. I know that we...