 good afternoon everybody last session of the day we're in a fairly tight room for a lot of people here this is the traditional Drupal security team panel which typically does not get this type of attendance and also the Drupal 7 end of life announcement which I'm guessing is what most people are in the room for oh good Tim welcome and Narayan welcome so we're going to start off with a introduction to the security team members that are up here Tim is actually the CTO of the Drupal Association he's not a security team member but he has some slides that he's responsible for and I'm glad he made it so security members your name and your pronouns my name is Michael Hess I go by he him his and my favorite vulnerability is an old what not everybody has a favorite vulnerability this isn't just something you introduce yourself with when you're in casual conversations recently I've been going with injection but not like sequel injection or even LDAP injection old-school injection anybody remember what the first like mass use of injection as a vulnerability was that like people actually exploited most of the time without knowing what it was I'll give everybody a hint to six zero zero pay phones you could play recorded phone tones into a phone and it would record that as money being deposited it was an injection based on the switching fabric that didn't quite know what was going on and my favorite breakfast food is French toast Benji I Benji Fisher my pronouns are he and his but if you call me they then that's fine me to my favorite breakfast food is grape nuts with yogurt my favorite vulnerability was Drupal Geddin because it happened fairly early in my Drupal career and I did patch my site in time my name is Jess I'm XJM on Drupal.org my favorite breakfast food is probably eggs over medium I'm an overlap of vegetarian so that's how I get a lot of my protein and my favorite vulnerability not a vulnerability per se but I'm gonna say left pad because it got people to start reducing the size of their NPM bills so I guess favorite but not daily breakfast food would be pancakes you know with chocolate chips or bananas or something favorite vulnerability one that Kali pointed out recently in a local government site where the using an API that lets you for some reason pass in the endpoint so if you wanted to you could pass in your own website and it would pass in their Twitter credentials and then you could take over their Twitter account and apparently it for six months he's been calling and them every number available and they just ignore him so so very soon a certain prominent Twitter account it's not that prominent as a local government hi I'm Kathy Thays my my pronouns are she her or they then oh here and I'm a he him Peter let's see my favorite breakfast food is burritos especially when I wrap them and then fry them in the cast iron pan after making them it makes much special good my favorite vulnerability is multiple types of information disclosures because usually it's like not and it leads to some interesting conversation thank you everybody okay so what's the Drupal security team we are a group of individuals who work to improve the security of the Drupal project I'll get to what that work looks like in a second but we are made up of individuals from around the world working at a variety of different types of organizations and some of the credit we have for this comes from these organizations security advisories like issues get issue credit assigned that issue credit is often tied back to organizations and so this is our this is the organizations tied back to them so we often get questions like what does the security team do and I'm gonna apologize in advance there's a lot of slides to get through so I'm gonna go a little fast and save time for Q&A at the end what does the security team do mostly we coordinate this process known as coordinated disclosure to help keep Drupal secure you are familiar with the output of that process that are those Wednesday's emails or the Twitter notifications that we that you see we also assist or provide support with Drupal related security initiatives we coordinate with other open-source security teams we act as that point of contact into the project we do educational events related to security such as what we're doing right now we work with third parties that might be interested in helping core maintain security we monitor trends around hacked sites and we triage security research reports now obviously when we talk about what we do do sometimes we have to talk about what we don't do we don't proactively search for vulnerabilities in core in other words we do not sit down and you know check out a get repo at random and go through line by line and look for vulnerabilities as part of the security teams formal duties we do have team members that actually do do that work but it's not a formal task that we set out and we don't help fix individual compromised sites so you know we if you reach out if your site gets compromised we we don't help you with that we may point you to a vendor or the marketplace rankings to find someone to help you fix that but we don't do it we do keep track of them because we're interested in looking at trends especially right after the release of large vulnerability coordinated disclosure is the process that we internally follow to release security issues and so you know it's really easy to read those Wednesday emails and be like yep that's easy there's a lot and I mean a lot of work that goes on behind the scenes to release those Wednesday emails and so you know coordinated disclosure here's a flow diagram of it I apologize for those in the back this is a little small but effectively a vulnerability gets reported to the security team we do some initial triage on the vulnerability to make sure it's a valid vulnerability you know if a user if a security researcher reports that logged in as UID one they can use full html as an input filter and then execute JavaScript we don't consider that to be a vulnerability but assuming it is a valid vulnerability we work with the maintainer of that code package to work on fixing the vulnerability this is typically a back and forth eventually the maintainer gets a fix somebody's reviewed the fix and make sure that it looks sane and then we set a release date and draft the security advisory and then you get your Wednesday emails there's more to it than this but this is a overview of what this happens and then hopefully you get those Wednesday emails and if you're running the effective code you stop and upgrade to the new version so that you can maintain security the easiest thing to do to help keep yourself secure like the lowest easiest like barrier is to make sure you're running current supported code that brings us to our next topic which is Drupal Stewart so Tim I don't know if it works so Drupal Stewart is a product really a service that comes from the Drupal Association that helps provide a little bit of peace of mind and an extra kind of bandwidth for you as a site owner to manage security updates for your site so what is it it's a web application firewall product so if there's a known vulnerability a serious vulnerability coming up it's highly critical it might be mass exploitable before that vulnerability is disclosed and the update is released we enable firewall rules to help protect it from being exploited so this is available for customers of the program directly or major partners hosting platform companies like Aquia and Pantheon for example that are part of the program and can protect their constituent sites in the same way if you're not totally familiar with what a web application firewall is doing basically we are not updating your site we are not patching anything we are looking for the like formula of a request that is inbound and if it matches certain attributes that would trigger an exploit we are blocking those requests before they hit your server so this is what's closing this gap between when that release happens on Wednesday and when you're like well I'm in Australia I got that email at 3 a.m. and I'm on holiday and I just don't have time to do this right now if it's covered by Drupal Stewart you can say I'm going to choose to do that update at 9 in the morning on my next business day because you're covered in this gap until you update so this is particularly helpful also if you are at an academic institution perhaps who manages like a thousand sites and coordinating the update of doing all of those in like a couple of hours is difficult for you there are some limitations though so it'll only apply to these highly critical core vulnerabilities sometimes we might choose to provide coverage for something like less severe in part just to exercise the system make sure it's working and there also might be kinds of vulnerabilities that just can't be protected using web application firewall rule it's also possible that the the rule the request is blocking might have false positives might block some legitimate traffic in certain cases and that's something we look out for so to run through this very quickly the way we decide when we deploy this program is the security team identifies as a vulnerability that they think is mass exploitable we decide whether it can be mitigated with a WAF and then in the PSA we indicate either yes it will be covered by the Drupal Stewart program or no it's not something we can cover from there we communicate that with our partners and we try and enable those rules in a monitor only mode before it's disclosed to in part tell us is someone already trying to exploit it that we don't know about is this actually a zero-day and we don't know and also to check for false positives so we review these sort of monitor only logs and then prior to the actual release day when the vulnerability becomes public we enforce those web application firewall rules and the release goes out as normal so this is not a gate on the security releases the code is always free and open source remains free but this is again just an extra tool to allow you to schedule when you're responding to these security issues it is available in three tiers you can purchase it directly from the Drupal Association and there's a revenue sharing program to support the work of the security team there is a there is pricing for sort of standard and enterprise sizes so directly from the Drupal Association from certain hosting partners and so on the partners that are involved in this they have to sponsor a security team member they have to be supporting partners of the Drupal Association and they have to be major contributors so this is not something that's generically available to any web host it's something where we work with trusted folks who are deeply involved in building and securing Drupal so with that I will hand it back to Michael. So I think most of you are up here we've got two upcoming policy announcements that we are making this is kind of shared as a preview these are pretty much agreed to there may be small changes that change between now and when we actually publish these which will hopefully be sometime later this week but this is a preview and while there may be I don't know a hundred people back there please don't hold me to this but it they're not going to change much we are changing the security advisories for which we do scope changes for so right now pretty much every security advisory we will publish every vulnerability and there are some that are an enormous amount of work for us to do internally and the use case of the actual exploitability of this is low information disclosure is a great example I'll give an example an actual real-world example here you have a website it allows comments on nodes comments are placed and a node gets unpublished for some reason so this content is now unavailable but you have a role at your organization that's designed to review comments they can still see the comments that were left on that entity prior to it being unpublished and they can see the entity title but they shouldn't be able to because the entity is unpublished and they don't have permission to do that that is technically information disclosure the risk is very low previously we would have debated about fixing that publicly we are going to start moving that just I'm sorry debated about fixing it publicly and probably might have gone either way the policy change here is we are going to end up calling these bugs and fixing them in public and releasing them publicly denial of service is another example here denial of service is one of these things that you know yes there are some examples that are egregious but for the most part you can fill a database log or some other resource consumed entity by doing something repeatedly you know they're you know an example of here is something that generates any you know 25 lot watchdog events when you see a single when you visit a single page and watchdog is going to the database not to syslog which gets a rotated over and you could in theory fill the database we're going to end up taking we do take most of these public now and we're just codifying this as these are going to become public there's going to be a couple others that probably get added to this as examples but the low of the complexity required to exploit and the risks to the individual sites are really what we're aiming here is it worth us spending the time to fix these in private or should we make them public and get more eyes on them so that's the upcoming policy change and now on to the larger one how many people are here to hear about this topic okay so let's start with a little bit of a history lesson here Drupal 7 development started in July of 2008 the first alpha came out in February of 2010 and Drupal 7.0 was cut on January 5th of 2011 also in 2011 Google plus was invite only it was going to replace Facebook as the most interesting best social network ever Facebook actually came out with its timeline view which was innovative and disruptive at the time the Mac app store came online we were running IE 9 which is still better than IE 6 and Android 3.1 and Microsoft's zoom was finally shut down who know whoever had a zoom anybody yeah okay so we in some people like their zoom so we have gone back and forth with this as I'm sure all of you know we have done extensions we did the first extension during COVID we did another extension we went to a model where we would default to announcing if there was going to be an extension or not as opposed to just announcing the extension we've gone back and forth with the way we've handled this and honestly it's been it's it's you know there's every time there's a lot of communication and I think we've reached the point where we are finally going to end of life Drupal 7 and there's a date and we won't change the date so we are finally going to end of life Drupal 7 on January 5th 2025 that is effectively a year and two month extension from the previous end of life the previous end of life I'm sorry from the previous extension yeah so it was supposed to be ended in 2023 we're bumping into year in a few months you'll notice the January 5th date lines up with the birthday of Drupal 7 and so that's that's not the full reason why we're doing it that way but that's what one of the things that you know just a nice 14th anniversary thank you I'm gonna be clear here there will be no further extension this is it we're done you're not gonna see a PSA from us in July of next year being like just kidding everybody two more years no it's over which means it's time to migrate it's now time you know if you're if you're an organization like like mine is I work for the University of Michigan oh it's been extended we'll just ride out the extension oh it's been extended we'll ride out the extension I'm assuming other people have been doing this too by show of hands yeah so the train is coming to an end it is time to migrate now some of you may be facing a lot of work to do this migration a lot of work and some of you may be dreading that we have some assistance for this I'm gonna ask him to come back up and talk about it yeah so the Drupal Association is going to try and put together a resource library for all of you folks who are still on Drupal 7 who still have properties to migrate that includes us Drupal.org is still largely Drupal 7 so we understand the situation you're in and what you're working to do let me make that very clear a big part of this in addition to just being a resource library documentation materials is we're going to feature certified migration partners so these are people who are contributors partners of the Drupal Association and who are well qualified to help you with your migration needs to help you get from Drupal 7 to wherever you need to go if you are out there and you're part of the agency audience and you're interested in being part of this you're already a certified partner of the Drupal Association or you're already working on that process or you're excited to get started we certainly love to have a conversation with you those partners will be paying a percentage of deal sizes to support the Drupal Association and to support the work of the security team because we need to make it financially responsible and feasible to put in the investment in making this happen so if you're interested in becoming a partner a migration partner rather than being one of the end users you can reach out to us at partnerships at association.drupal.org and if you are one of those Drupal 7 site owners you can look for this resource library to be published soon on Drupal.org and we'll be reaching out with communications throughout this 18 month window following DrupalCon that folks have to get to their next solution. And I'll add on to this if you are an agency that is interested in doing site upgrades please reach out to this email address and become a partner and if you are a site owner please consider using one of the agencies that are on this list it helps the entire ecosystem get better by doing this so please support us supporting you by with the extension and go through this process we will end up with some marketing material on this and some pages listing the partners but in the end we want you to migrate like that's the bottom line we're putting this list together to help all of you migrate we're also putting it together to help us because there is a revenue sharing here but you need to migrate Drupal 7 is closing its doors you know so go someplace else obviously going to Drupal 10 would be our first choice going to another open source content management system is also an option here taking your Drupal site and just making it a static website you know I know that as I was going through my site audits I'm looking here and some of these content pages haven't been updated in several years as like I could just turn this into static HTML software as a service or taking the site down which reduces all the technical support that comes with that there are some upcoming changes to Drupal 7 before end of life and so as that 18 months is in the future there are some things that we are doing to start changing the ecosystem slightly to encourage end of life so probably the big one here is unsupported contributed modules if you go back to that original slide I had where we talked about the coordinated disclosure process the second step in that process is the security team contacts the module owner and says hey is this a valid issue work with us there's a whole escalating thing that happens there where you know we ask them we ask them we send them emails we will if they're working for an agency sometimes we'll send the agency emails but eventually if the maintainer doesn't respond we mark the module itself unsupported what typically happens is people will come forward and be like I use this can I be the maintainer I use this can I be the maintainer and so then we have to go through the process of marking the module not unsupported this is time-consuming and so for Drupal 7 specifically an only Drupal 7 we're not going to do this if we mark a module unsupported for Drupal 7 it's done it will remain unsupported through the end of life which it would then be marked supported for anyhow what does this mean if you want if you've got a Drupal 7 module that you use heavily in your sites apply to become the maintainer now I'll pause for you all to do that so apply to become the maintainer now and then you'll be added to that list of people who we contact and we don't have to go through unsupporting it saves us time it saves you time it's a win for everything you do not have to maintain Drupal 10 branches you can apply to be a maintainer solely of the Drupal 7 branches this policy does not apply to Drupal 10 modules with Drupal 10 or greater than seven releases moderately critical issues in Drupal 7 alone we will have less support for them meaning that a non-mass exploitable moderately critical issue even if it impacts a future-dated version of Drupal may not get fixed in Drupal 10 depending on how that risk score I'm sorry Drupal 7 thank you depending on how that risk score how that risk score pans out for Drupal 7 so there may be an instance where we fix something in Drupal 10 and we do not fix it in Drupal 7 based on the differentiating risk scores PHP and my SQL versions so effective July 1 we are only going to issue patches for PHP 5 6 and above Drupal 7 supports I think it's 5 2 5 I think it's 5 2 and there's no test spots for 5 2 which is a whole nother problem and so we're gonna we're gonna bump effectively bump the minimum required version for Drupal 7 to PHP 5 6 we may before end of life bump that to a higher version of PHP I want to point out here that Drupal that PHP 5 6 and PHP 7 are both end of life and yes there are vendors who may provide support for them but they are technically end-of-life products Windows support Windows only security issues will no longer be patched so if there is a issue that is only an issue on Windows we may not patch it now yeah maybe one of you I do know there are some organizations out there that have requirements against running not Windows operating systems and that's how you end up hosting a Drupal site on IIS you unlike when Drupal first came out Drupal 7 first came out we now have Docker Docker can host your Drupal site on your Windows server so there are ways around this as mentioned earlier Drupal is kind of getting old there's a lot of third-party libraries out there a lot of third-party libraries out there that where they may say hey we're not going to support this or yeah we support this library but only if you're running PHP 8 which obviously is not a requirement for Drupal 7 so we may end up having to mark some third-party modules as as unsupported based on their dependencies on third-party libraries earlier you heard Tim talk about Drupal Stuart Drupal Stuart is we may post EOL we may there it's in bold may choose to extend Drupal 7 Drupal Stuart rules to our Drupal Stuart partners may that's not a final decision yet but it's easy enough for us to do it in certain circumstances and it's it's quick but that's a DA and security decision and likely gets evaluated on the release itself now as of right now today there are no vendor support plans after EOL so what's EOL end-of-life running software past its end-of-life is risky this is not just Drupal this applies to all end-of-life software I just saw a machine in this building running Windows I think it was 98 end of life what happens the security team no longer provides coordination for end-of-life most enterprises won't allow end-of-life systems to run security frameworks don't allow it within Drupal specifically what may happen well at some point after end-of-life Drupal 7 packaging is not going to work the Drupal Association has to maintain all the code that does that packaging work and it's different than modern versions of Drupal and so at some point those operations will stop Drupal 7.x branches for all projects will be marked unsupported Drupal 7 relies on a bunch of XML data sets that is going to go away in more current versions of Drupal these XML data sets you know you probably don't even know they're there for the most part but Drush relies on them so if you've ever done Drush DL module name that is using that XML data set and that will likely go away sometime after end-of-life obviously the testing infrastructure for Drupal 7 will be shut off Drupal 7 is going to probably get start getting flagged as insecure based on third-party scans and Drupal 7 issues that are reported the security team even highly critical ones will be made public with or without effects and Drupal 7 sites will be made will be will display a message that they're insecure what doesn't change after Drupal 7's end-of-life anything related to Drupal 10 nothing is going to change related to Drupal 10 11 etc and the git repositories that have that Drupal 7 code they're not going anywhere okay if you are not in the room and you're watching this on a recording you can email us questions at security at Drupal org and we will be happy to answer them but for all of you who are physically in this room I got through my slides and we have time for questions and answers okay so we don't have a microphone in this room so I'm going to try my best to repeat the question I saw your hand go up first so right now I'm sorry thank you thank you so the question was how will Drupal 7 indicate that it's insecure after end-of-life what mechanism is going to be used to do that and does anybody want to take this okay so right now Drupal 7 and we did this with Drupal 6 every time Drupal 7 checks in for updates it pulls that XML data and we basically are returning a custom message through that XML data letting people know that this is unsupported the way we did it in Drupal 6 which is probably similar what we did is we made the update status think there was a version fix which automatically tells Drupal 7 that it's insecure and then the link takes you a page explaining what's going on to clarify that that's in the admin interface when you're looking at the sort of status report for whether currently updates available it's not like that a public banner on the top of the front of the site no we will not be defacing the public sites so yeah it's when you log in with in with a with a privilege that lets you see it it will not just show up on every Drupal site thank you Tim any other questions that was a very well-worded question the question was is there advanced reporting within Drupal steward to talk about how many times requests were blocked what might have been affected basically can we give you back analytics to say how effective the Drupal steward program was we have the raw data to gather that it has not been added to our dashboard in its current form but that's a feature request that I think we could probably probably prioritize and wait Tim also you don't post all them just also to say like if it's hosting partners but yeah so that's an important distinction right yeah so that would be the case for anybody who's just choosing to purchase Drupal steward through the DA's program directly if you're with one of the hosting partners who has coverage who's partnered with us any reporting would be based on whatever they can offer so again currently those partners are awkward and pantheon so it would be you'd have to have a conversation with them about whether they can report on that specifically but if you're purchasing it directly through the DA service that's a feature we can work on for the dashboard and you can reach out to me directly and I'm happy to have more conversations let's go here correct so so let me let me summarize the question the question is will there be extended support like there was for Drupal 6 for Drupal 7 and as of now there is no there are no plans to offer extended support for Drupal 7 and the follow-up question was if someone has a patch could they contribute it to a public get repository yes it won't be coordinated by the vendor program that used to support it so anybody can make a get repository clone Drupal push it there and designate it as that but they don't get security team support of here is the repository and you know vendors vetting those patches but in theory oh please go ahead nor security advisories or releases from Drupal.org right so no essays no PSA is no in from indication in the update status but you could still post it to an issue I suppose as well for the canonical repose because those repos will still be there there the question was will people be committing these patches and the answer is no next question so let me let me go a little bit towards the back you sir I think a lot of that content should be I'm sorry to repeat the question there's a lot of content not just related to Drupal 7 but going earlier to six and five and things like that I think absolutely we'd want to move that to either an archival space if not remove it entirely we just certainly we would want to make sure that you're not being fed Drupal 7 data when the support you're looking for should be for Drupal 10 or above so yeah it's something we'll have to look into and thank you Peter for making sure we repeat the questions I'm going to go to the very back I know you yeah yeah so the question was the question was first of all that people are happy that there is an extension but wondering what the motivation behind the extension was given that a lot of there are still a lot of Drupal 7 sites out there and I guess they're just being up until now people there hasn't been much incentive for people to actually do those updates since it's still supported I would say that one of the biggest factors is that it is very time consuming for us to provide Drupal 7 support and it in the past has significantly slowed down the release of security advisories that affect both Drupal 7 and Drupal 10 and I mean to the point like we had we recently had one that was a coordinated release for Drupal 7 9 and 10 that took over a year to resolve with the security team meeting about it every two weeks so that's the level of technical complexity that I can add to something and we also are hoping to have overlapping so this isn't we haven't decided this for sure yet but we're hoping to have overlapping major version support again for like Drupal 10 and 11 11 and 12 and so on so that you can so that Drupal 10 support would be extended all the way to the release of Drupal 12 instead of only there being this overlapping year that there's been for the past couple versions and there's just no way we can possibly do that with Drupal 7 also being supported so that was a major factor in deciding this is this is final of the time also this past year we did finally surpass the mark where there are more Drupal 8 and above sites than Drupal 7 sites so that's exciting I will I will add on to that based on the conversations we've been having people needed a hard date and we gave them a hard date and we're giving them a partnership program to come and get help with their upgrades and so we're hoping that the combination of the hard date and the combination of the partnership program is motivating people to get off I don't think well yeah and so that's yeah does that I assume that answers your question okay let's go here because you've had your hand up for a while thank you this is regarding the partnership program I I'm a solo consultant I'm not a big agency I do contribute but I cannot contribute to the level of our agency are there opportunities for solo consultants like me to partner in migration for people 7 to 10 that's a great question so the question was are there opportunities for solo consultants sort of the freelance level or small consultancies you know under 10 something like that to participate in something like a migration program to be honest I would think many of the like larger scale agencies who might be interested in this probably wouldn't want the deal sizes that are in the smaller side of this range so I think it would be worthwhile for us to provide opportunities for the small site owners to be connected to the smaller folks that's worth thinking about I haven't totally sort of resolved that question in my mind but I would I would appreciate if you would reach out to me directly and we can think about that you want the partnership email which is what I'm trying to find sorry that email again partnerships at association dot triple dot org I'll leave that up for one more second as people pull up their phones to take pictures of it yes these slides are going to yes well though we'll we'll attach the slides to the session I assume we we can do that yeah we're also going to release our standard public security advisory within the next week that will contain all of this information in not slide form the public service announcement it's it's people might not know what's our standard the public service announcement is the canonical information these slides are just kind of a preview so our intent is to announce it to the entire world at once the entire world is not at this Drupal con so all of the official information will be in that PSA any other questions comments concerns yes um so the question was are the policy changes around releasing moderately critical non mass exploitable issues in line with standard best practices or are they a reflection of resource constraints and if we had more resources would we change that policy and so let me take the second question first I don't think the answer I don't think we change the policy if we had more resources some of these issues are not worth fixing in private that's not to say they're not bugs that's not to say they're not security impacting bugs but the amount of work to fix them in private when they can be fixed in public and will likely get done with more eyes on them is probably worth that trade-off as far as the resourcing question goes you know we'll always take more resources uh give me one second uh if you're interested in joining the security team uh this url unfortunately is going to redirect you to another url but the other url is too long so let this url redirect you um if you're interested in working on the security if you're interested in joining the security role always take the resources but I don't think these are being led entirely by uh by by resource constraints we are a small team and we are resource constrained like everything else um but I don't think you know this has kind of been the practice we've been doing on and off and this is kind of codifying that practice into public uh into available for public consumption anybody have anything to add on that I would also add that different organizations and projects have completely varying ranges of what they consider what they do coordinated disclosure for or not and there are also organizations and projects that don't practice coordinated disclosure at all um so it it is kind of up to us but um I think something that Michael was trying to say that isn't really clear is it's it's not only a matter of resources for the security team there are certain kinds of fixes where like to taking the the label information disclosure like we've issued like five or six security advisories for the exact bug in different entity apis in the past couple of years just for that thing about the label the title of an unpublished thing being shown to someone who's already a content editor so it's it's it's very low risk very not a huge issue and so we had to keep doing all of these one-off changes for different entity types um whereas in public we can just add an api that handles the label in a safe way and do it once instead of 18 times the code will be cleaner it'll take less time and um probably actually be done faster as well I will say that when we talk with our our peer open source organizations about what the security team does most of the time there's just this look of shock on their face because we are we take on a lot more than most of the other organizations do including all of contrib space uh that have opted into coverage but most open source projects don't take on contrib space the amount we do and most won't publish things for bugs in which it requires an elevated role to have access to to see the information um obviously if an elevated role that shouldn't be able to change the information can change the information that's a different story but this is you know seeing that there's a field that exists even though you don't have access to see the content of the field and you're only seeing the label like there's a lot of things where it's like oh that that's a security bug and yeah it is or it was um any other questions comments concerns thoughts it's very quiet in here thank you thank you thank you for your kind words to repeat the things uh well thank you everybody and uh see you around the conference yeah coming up soon the welcoming reception in the expo hall