 We are good. Oh, come on up. We're welcome. I don't feel like I'm just taking a seat. Have you, like, right? All right. So we are here to talk about the proposed core privacy initiative, what it is, and why we need it now. The first thing we want to get into is why does Drupal need a core privacy initiative? This is the first question we get as we start to talk to people about why we want to do this and what we're wanting to do. And they say, well, why do we need privacy and core? Contrib can handle it. And I think it's best summed up by Drees did a article for CNN recently. And if you haven't read it yet, please go read it. But the title of it is, the internet's become a dark place and I want the old one back. And it's all about how progression of tracking and analytics and a lot of the scandals that have come out have caused the internet to become a different place than when we originally started creating. And a lot of us as developers, that started a while back, got into privacy or didn't really focus on privacy. We're so focused on building that all of a sudden the tools that we were building were being used in ways that we hadn't imagined or hadn't wanted. And so why care about privacy? First and foremost, and this is something I'll pontificate on all day long, is I believe there's an ethical responsibility as developers for us to enable privacy in the tools that we built. Inherently, we are building tools that can be used for good and for bad. And we should be also giving those tools to be able to allow our users and the people who are creating with it the ability to do that. So first, I think there's just an ethical reason. And folks who've been, you know, we're in Europe now. Under GDPR, that was kind of the first salvo. That was the first real big legislation around privacy. But there are more coming. For the US folks, there is CCPA from California, which all internet roads lead to and from California. So it's going to be widely adopted in the US. And then eventually, there will be more US-based privacy laws. Right now, each of the states are doing their own thing, but GDPR kind of led the way. So this isn't something that we're going to see a regression from. It's we're only going to see more and more regulations, and we're going to have to do with them on a larger basis. And then one of the things that we'll get into later is a lot of the projects that we're building now are starting to come with requirements for privacy in them. They're saying, you have to meet GDPR. You have to meet CCPA or you have to have these certain features enabled in them. And as developers on Drupal right now, a lot of the times we're having to bake those ourselves. We're having to go out and do our own thing. We're not lawyers. We don't know exactly what we need to build. And our clients are kind of dictating that to us. And then lastly, we have been working with Jamie and myself and Peter have been working with a larger group of CMSs, WordPress and Joomla and Umbraco and type of three. And I will say that while Drupal definitely leads in an innovative front from the development sets, when it comes to privacy, we are in the far back. And a lot of the frameworks that we're up against and a lot of the projects that we're bidding on all have privacy baked into core. So that puts them a step ahead of us. So Jamie's going to talk about what the initiative is for us and what we believe that should be brought into core. Cool, yeah. So as Chris said, we, with Peter's company, we worked along on a Contrib GDPR module. And there was a great deal that we could do in that GDPR module and that we could do in Contrib to help these things. But we feel that there's quite a lot that if it was in core, it would enable other modules to work with it much more effectively. And things would be a lot easier for us to build. The things that we had to do were quite, we had to build on top of the field API a lot. So I think the core functionality that we think needs to be in core, although this is definitely a conversation, is this concept of a framework for identifying, exporting, and raising information. If you have used the GDPR module and we've given some talks showing how it works, you'll see that it basically improves on the field list in core. So you see a list of all the fields. I'll link to the user in any way. And you can change the settings on those fields. And then there's a framework for actually exporting those things. If it was possible that it was something in core, then we could start trying to get modules to provide sensible defaults. Because setting up all of your field settings from the start takes a long time, because there's a lot of data in Drupal. So if modules could provide sensible defaults, that would be great. If modules could declare where it is that it's got private information and the kind of ways that it would deal with those things, that would be really great. And similarly, any kind of integration for any third parties, incredibly important for you as a site owner to know about those things. Yeah, so that's the stuff. In addition to that, and a lot of what we're basing this off of is the work that's already been done in some of the GDPR module to date, but then also looking at some of the other programs and frameworks that have privacy in core and what they're doing. One of the things that I highly respect of the WordPress project is that all of their plugins declare into a core API. Here are all the tracking scripts that are in my module, and here's all the data that my plug-in is collecting. And then the site builder can go to a single page in the back end and have all of the information there. WordPress goes one step further because a lot of their customers or a lot of their users are smaller sites that don't have a larger team behind them or a legal team behind them. And they actually have a one-click privacy policy creator, so you click a button and it will take all the information that all the plugins have declared, put it into your privacy policy and put out on the other end a compliant privacy policy page for somebody who hasn't done that yet. Obviously one size doesn't fit all in that, and so there's obviously some tweaks that need to happen from there, but just being able to know if somebody goes off and installs a module that has a tracking script on it that you don't know about or a module's injecting that as a developer or as a customer, your customers, they may not know that, they may not disclose it in their privacy policy because they may not know and then all of a sudden they're out of compliance. So having that core functionality, not only for modules to declare, hey, this is private information, but hey, I'm also tracking you in these ways, brings a lot more light to the users. And one way in which there's gonna be a core versus contrib collaboration is this concept of the actual data requests and how they're managed. So for some smaller sites, you might wanna make it so that somebody clicks a button and they get the data exported out of it for a larger client, especially when you get to the enterprise, you're gonna need to build actual sort of workflow management tools to help members of staff process those requests. We find a lot of the time in Drupal, you'll have fields that are in the maybe or anonymize section of Eurasia where you'll have like notes fields that somebody randomly is typing stuff that might have personal information about someone and you have to check it physically. You might have third-party integrations that you have to manually go and check that information. So what we're gonna find is that probably in core that we can get a very basic UI that in contrib we can extend for the more complex scenarios. And I think the privacy initiative will be a really great place to be a single point where you can see, okay, some of it's in core, but you can also see the collection of core contrib modules that are within that initiative. And so with contrib, what we're proposing is to not just consume GDPR into core. I think that would be short-sighted and it also is too specific. So part of what we're looking at is taking the baseline of privacy policies that you see from GDPR, CCPA, and some of the others that are coming out, they all have a common core to them as well, right? Right to access, right to be forgotten are the big two. And then disclosure around what date are you tracking and how. So if we can bring those into core, then it allows the contrib space to then specialize. So if you're a site that's in Europe, you will then install the GDPR module, which is a contrib module that will extend core to allow you to get into those specific regulations. And as each jurisdiction starts having their own, you can have contrib modules that specify those and you're not having to, once CCPA comes up, say, oh, I'm gonna take the contrib module for GDPR, I'm gonna have to hack it a little bit and now it's this. It allows that work to be shared a lot better. Is there a question or do I see a hand go up, oh, sorry. So that's kind of the big one there. Like we said, the privacy policy generator, it's all building on top of the ability to declare into core, here's what we're tracking, here's private data, here's where it is, gives contrib the ability to then go out and do what it needs to do. Cool. So again, we've been working with a cross CMS privacy group that we've kind of propped up with some of the core contributors from various different projects. They're represented here. Jamie, myself and Peter meet with these folks we've gone through. We actually have a GitHub repo that has a core privacy statement that says here's what we're going to try to do. And the goal behind this is most of these technologies are all based on PHP, but for the most part, what we want to be able to do is be proactive instead of reactive in the legislation space and be able to say, rather than us shaking our fists to GDPR and saying this is creating so much work for us, as a web community, the technologies represented here represent almost half of the entire web as we know it. So we can declare here's a baseline for privacy that we are going to stand for and then extend upon and then we can start being involved in the process of legislation rather than having to always be reactive. We can actually be proactive and take a stand for ourselves. Yes, what's next? So for what's next, we want to be able to obviously make this an official initiative. To that, we're going to need obviously your support and community support. We're going to need some core commuter support as well. But then also we're looking at, are there various funds or grants that we can apply to that can give sponsorship to this? And then also, is there private sponsorships that we can bring in to have folks work on this? So we're currently talking to various companies and folks in the community and are always open to ideas there. And so with that, that was kind of our, we wanted to get that out there, but we wanted to leave, because this is a shorter session, we wanted to leave a chunk of time to ask questions, answer questions, come up with ideas and thoughts that we can then go through and bring these ideas back into core or back into our initiative as well. So at that point, or to this point, we'll open it up for questions that you may have. Go ahead and stand up. There is a microphone here if you want to use a microphone. If not, we can just repeat your question over the microphone here. Yeah, also particularly any comments you have like on how you've, as I don't know, agencies, developers, you've found GDPR and the privacy stuff has impacted you and any ideas you have on what you've seen in terms of what should be in core and contract will be interesting to know as well. How great is the, how big is the risk? Because you say, Drupal is in the back of privacy and it's here, but how big is the risk? I think for us, especially as we are seeing Drupal move more into the enterprise space, the risk gets greater and greater because as we start to go up against other CMSs that have this in core, that's just a checkbox item, it becomes something where, oh, well, you guys don't have this, this other platform does. Adobe has this or WordPress has this. So then it's now a checkbox in the weight that people put on their choice of CMSs. One thing that is definite is this is not the idea that we are making Drupal compliant. It's not 100% compliant. There will always be work that has to be done on top. The idea here is to give a base level of tools for people to be compliant and then start to compete in the projects that are trying to choose what CMS they're getting into. Drupal will actually be able to be competitive in that landscape, because right now it's very much not. And it's starting to be noticed on the broader CMS talk, if you will. Yeah, just one thing about that. We are finding a lot of the tenders that I'm seeing tend to have as a line something to have right to access and right to be forgotten, particularly. And then auditing is useful because if there are any problems, it helps you then not get fined or communicate with them. So I think it's something that if the Drupal community could show that it's taken it seriously, because this tends to be a checkbox, it's not that a lot of people wanna pay a lot of money for privacy, but it tends to be a checkbox for you to get it at all. If the whole community has an eye to this, there's a kind of sense in which we're safer together because we can then say, I can then link in my tender proposals, I can link to articles about it, I can do a small little thing, write about it, post something on Drupal.org or post something in the news that shows that Drupal's good at this. So I think our risk is in lost opportunities more than specifically being necessarily fine or anything. Though that is possible, that's why I think the risk lies. So Paul Johnson from the CTA Digital in the UK, I can definitely agree with what you're saying, but the tenders, we work with membership based organisations, government and charities. So it's a massive issue for us. And it's kind of a gate if you haven't got those things because a massive onerous task to actually prove that the system is compliant. I suppose I was a partner as the question is, are you gonna approach it similar to the security team perhaps where there is like a responsible disclosure where perhaps you find an issue and then it's maintained and then there's kind of good governance around it. So it's very reassuring to these purchases. Yeah, so one thing is with the Cross-CMS group is we put a lot of energy in looking at what everyone else has been doing and in WordPress, there's been much more looking at the legal side of things, are doing a fantastic process. So one thing we did do at the very beginning is they started building questionnaires for modules in their marketplaces of things that you'd have to fill in to show that you have taken privacy into account. I think if we started with a privacy initiative, we could move much more into that in the kind of, you know, signing up for the module kind of stuff so that people have done things like write somewhere what data they've stored, et cetera. And then maybe we could go one step further and add to the security team one person maybe who checks that people are doing stuff like that. I think that would be really helpful if there was a kind of, you know, this module isn't stealing people's private information without any consent because this was made ages ago and they forgot about it or something. So I think there is some scope for that. And we have talked about that, but yeah, it's sort of one separate time. And in WordPress, one of the interesting things that they do is that if your plugin declares, click this box or download this plugin and you will be compliant, you get removed from the repo because there is no guarantee of compliance. So that's one thing that they have specifically gone out and said we will not allow that. And on the flip side, you can also get warnings just like we do security warnings through responsible disclosure and say, hey, you aren't disclosing this to your customers, you need to disclose it or we'll disclose it for you or we'll fix it for you. I think Drupal has a framework for that type of responsible disclosure more than other CMSs because we have the security team that we do. So yes, I think that this would have to get involved in some sense in the module repo as well. So I'm going to maybe be a little bit of like a devil's advocate here. Please do. That's what we love. I think there's two things that come to mind on this. One is, as far as like sort of CMS cooperation and standardization, I've watched with some interest sort of the waning side of PHP fig. Right. This is sort of, you know, shadows of. Yeah. I know like symphony left and off and things like that. So I'm just a little bit sort of, you know, and maybe this is actually a good example of what it should be, which is more ad hoc, right? Yeah. So you're not starting up some new thing and putting numbers on them. Yep. So that's just one thought there. Yeah. The other though is that I think, and you know, in the US we're sort of mercifully, you know, behind the curve on some of this stuff so we can see how everybody else screws it up. But this strikes me as a little bit different from other parts of Drupal where when people ask me, right, to your point, is Drupal, you know, GDPR compliant or whatever. It's like it's all in your implementation. Right. I do think that despite best efforts, there might still be a perception that if it becomes an official initiative and you have all of this sort of reporting and things like that, that it is more of a false sense of security than we offer on other things. Right. Because I think the target for this, like the large enterprises are gonna spend the money and they're already having to spend the money on time to do this. Right. So this becomes sort of a mid to low market made it. Yeah. Maybe more of a mid to low market of Drupal. And I'm just worried that that kind of initiative, like you know, that's, there's no sponsorship. There's not as much sponsorship money there as maintenance. So if we commit to doing something like this, I think it's very fraught. Right. It's a need in space. I think there's, for this especially, there's a lot of good reasons to ask like, if we should. Right. And that's my feeling. And that's why we wanted to have this session was to say, what is the feedback? To that extent, yes, in the US, we're woefully behind. We're catching up there. Facebook just got fined $4 billion. They pulled it out of the couch. They paid it and off they go, right? Like it's no big deal. Like privacy is seen as something that is a line item in your fine list that you get as a big company. That's going to start changing as, in my opinion, as CCPA comes online, there's a contentious bind between the state government and the federal government. And the federal doesn't like the states telling it what to do. And so I think the federal government is going to catch up very quickly. Once CCPA comes on, people are starting to sue. They start seeing the money flow. Businesses start getting affected. You're going to see things go through the federal docket a lot faster. And then to that extent, it's going to start getting more and more people saying that just like in Europe, this is a checkbox item. We have to have this. At the same time, what we're saying from core initiative is that this isn't a total framework. It's a baseline that you could then go build off of. And rather than having to completely rebuild piece by piece by piece, ideally in like our utopian society, could we share a PHP library amongst WordPress, Drupal and Joomla? Yeah, like we're all PHP based. We could write a common privacy framework and start doing that. That's a much higher lift and a much heavier load to carry. But I think that if nothing else, our involvement with the other CMSs has brought to light just how woefully behind we are. That was evident amongst us as we were going through that process of like, hey, we've got this, we're like, we don't. We have this, we don't. If you look at the GDPR module and how well it's built, it's 3,000 installs-ish. I think there's more than 3,000 sites in Europe that are running on Drupal 8. So that shows that a lot of people are going out and rolling their own and just trying to go on an ad hoc. So I think there needs to be, that shows that there needs to be some sort of baseline framework because there isn't an adoption like that. Nobody's been given that ability. So, but that's definitely part of the push and pull that we're trying to do is, should this be in contrib, should it not? So, we'll go here and then over here. Yeah, a quick question. So just, I think, yes, we shouldn't spend the time and the energy to work on that. Just as a general thing. As far as doing stuff like WordPress is ahead and what is the objective of the initiative if it's made official, like is it to catch up to it or to do it? It's to work alongside, basically what we want to be able to do is say, as Drupal developers, we're doing our best to provide the tools to the sites that we're building to be compliant with privacy and then just best practices. We don't have those best practices built into core like we do with accessibility and everything else that we have to be able to do as a program or as a CMS. I think for us, there's an ethical side of it that we should just be doing this. It's something that is a good practice that we should be building. And then as a second, it's, yeah, we're playing catch up now. Is it gonna be mimicked one-to-one? No, but it'll be modeled after what's been done because we've also seen where they've fallen or where they've had issues. And so we can learn from that as well. So we'll go over here, we'll do this question and we gotta be done, of course, because it's a short session, so. I just had an observation really, I worked for a UK regulator. So we've had to do extra stuff around it. We've also seen quite a big consequence for the Google Analytics Trafficking Drupal. Yep. And I was just interested, have you seen similar things elsewhere? So one of the interesting things along the lines of Google Analytics is when the WordPress community initialized this, the amount of plugins that said, oh, by the way, we're including tracking scripts was shocking, right? The number of things that came out through that. Site owners were all of a sudden given this list of, here's the six plugins that you had and you're like, wait, I only thought two were tracking me, right? So to that extent, I think it's going to air out a lot of that. But yeah, there's gonna be nuances to everything that we have to kind of get into. So the idea is give a base framework to then extend upon. And we'll do the last one here. I think it's awesome that you're already, that we are collaborating with the other CMS. I think we should keep in mind that our largest competitors are closed source proprietary CMS and they can promise. I'm not saying they make false promises, but they can, whereas we cannot. It's all transparent. So we should have answers. And I think we should have answers soon and show the world that because it suits all of us. Right, like if we're going up against Adobe and Adobe goes, here's our privacy framework and we are compliant because we've done all the audits on it. That may or may not be true based on the implementation. The reaction I don't like to have is when somebody goes, oh, is Drupal compliant? You go, well, right? Like that, it could be, doesn't really put assurance into the people who are implementing it. So yeah, just make a little comment about your devil's advocacy question. So like the first thing about the cost CMS thing, we're very different pieces of software. So the way we implement privacy tools, we're already finding it's going to be very different with human or WordPress or Bronco especially. So it's never going to be something like the fake thing where we're all going to say, we're agreeing to this. It's just learning from each other and we found that's already useful. And the second thing is, although when we first started, especially around GDPR, we put a lot of energy communicating. This doesn't make you compliant. It's just tools to help you do that. And we thought that there would be something in the UK that could guarantee you compliance. People use ISO 2701 for that, but there isn't anything that guarantees it. And everyone was worried about that. In reality, it's not been as big a deal as it was. We found that a lot of the regulators have taken a much more common sense approach to things rather than deliberately searching for fines. So I think whilst it is very important if we do a privacy initiative to say over and over again, it doesn't make you compliant. It doesn't make you compliant. It's not something that is such a risk that if we did privacy initiative, we would cause more damage than we have now. I think most people will know what they're doing. And any client says, oh, our tick box were definitely compliant. They probably don't care that much anyway. They're just using an excuse for it. So by us providing those tools to help people, I don't think we'll cause any damage. And we've learned a lot from the rest of the community on how to do this and we haven't seen that as a problem. I don't think we've had anyone come back to anything that we've done throughout our initiative and said, oh, you said you were compliant. Therefore, that's just been a non-issue, though we will still care about it. So I don't know if that helps with that. All right, so with that, we're gonna finish and bring Paul up. So, and if you guys have more questions and gals, feel free to grab us and talk to us throughout this week. We would love to hear your feedback on this because we're trying to take this to the core group, to sponsorships and everybody else. So devil's advocate, come, I love having a beer and talking through the deeper concepts behind this. So please come find us. Thank you.