First of all, it's a pleasure to be here. It's very nice to be talking at DEF CON, and four years after just this event, make me quit my job that I had so far and dive into this crazy botanical chain. So, let's continue. Alright, so I would like to start off with what back then was actually the vision of Ethereum. And the vision of Ethereum was actually not just a DeFi magic token machine, but it was going towards DeFi 3, right? And in fact, Ethereum comprised many parts, and the blockchain was just one of them. There was supposed to be decentralized storage, messaging, like Swarm and Whisper, and then I guess somehow crypto winter happens, a lot of things shifted around, and we're happy that we still have the Ethereum blockchain around. But to me, this whole vision of this Web 3 vision of building decentralized and privacy-preserving applications is still something that I find very appealing to going beyond just financial applications, because me personally, I mean, my e-banking is not the most exciting application I have. And in the meantime, a bunch of things happened, and a bunch of things have also quite some focus on privacy, like we heard already in the panel right now that we have mixers, right? So transaction and value can be handled relatively well in a decentralized fashion. We've seen a lot of applications there. We also see quite some movement on the storage front, right? So obviously, I give us Filecoin, guys, but also StoreJ, which I heard runs IPFS, fine, and a bunch of others. We also see a lot of computational-focused projects, which I turn again, many of which have quite some emphasis on privacy. But what I would like to talk about more is that for many of these applications we really need a fundamental privacy foundation to enable communication between users and dApps and between different components of these dApps, right? So this is what we're aiming to build with Popper. And I would like to go a little bit into the why. Like, why would we do that from an Ethereum perspective? So one thing, and I don't know if the Tornado guys are still around, but this is from the Tornado website, right? So if you try to use... Who here used Tornado, actually? Anybody use mixers? Okay, so you just leaked some metadata, by the way. So, yeah, this is what you find on the website. Make sure to use different IP addresses for deposit with dolls, we can run using Tor browser or VPN, right? That sounds fine, but actually neither Tor nor VPN are suitable in my mind to this DeFi level privacy which we're striving for here. So Tor is not decentralized at all. It's relatively easy to de-anonymize and there's like a body of research on that whole topic. And VPNs are primarily corporate entities that are gathering some data and making it available for whoever needs it or for whoever pays for it, right? So this is the business model of VPNs. Now, more specifically, broadcasting is not privacy-preserving. And I would like to highlight this here because I see a lot of conflation between kind of broadcast-based schemes and mesh networks. I think especially in Bitcoin and ecosystem, you hear that every now and then, we have this mesh network. This mesh network and that's why it's private, right? No, mesh network does not bring privacy and the same goes for any other broadcasting-based scheme. So I would like to briefly go through an example. So we come up with a hypothetical network. So topology is having some nodes and initially nodes don't know a particular transaction. Once they do know a transaction, we mark this X. In between, we draw some lines that show the edges, the connections of these nodes. And what's important is that this is totally public information, right? Anybody can query a note. Anyone can find out who has what transaction at what time. So our hypothetical network topology looks like this, right? And what we see is that as a transaction kind of ripples through the network and gradually reaches all of the nodes in the network, you can of course, what you were just seeing, you were a passive observer of the network, right? And you as a passive observer of the network were just finding out where this transaction originated from. And this is something that not just you can do, this is basically something that anybody out there can do, which is pretty bad for a decentralized system that wants to bring us privacy and has all sorts of nice features on chain. And that again is the reason why the tornado guy has made this suggestion, right, to use VPN or Tor. And finally, one example that I find particularly striking is today I think we still live in this frontier world, right? So to me, this is, we're really mostly at this Ethereum 0.1 stage, right? So what we see is that when you and your dad were on Osaka, you have metamas that connect to, well, default in Fura, right? Let's face it, that connects then to the so-called decentralized Ethereum. And what we increasingly see, and I'm happy that we have projects like Datna, Avato and some others and that you have your note in your living room that you can connect to, right? So this is what we can do and still like your hotel Wi-Fi provider, their ISP and everybody in between can pretty easily find out that you're accessing your service and that you probably just broadcasted a transaction on tornado. So what I would like to see is like a less revealing link between you and your dad and actually denotes that your interface. So this is what we want to do with Hopper to connect you in your wallet and to metadata private Ethereum network. Now Hopper is decentralized, incentivized, privacy preserving messaging protocol. So we don't build a channel application, people can build on top of that. Hopper is also a mixnet. So now we're going to work briefly in how we achieve this privacy. So mixnet basically means that note sustaining messages. These messages are received by a relayer which is short term caching them and we keep this updatable so that it can cater to different types of applications is then mixing the ordering of the transaction before they're relaying them in a different order. And what is important is that an incoming transaction and an outgoing transaction cannot be linked, right? They look different and there are some packet formats that are optimized for exactly that so that your traffic cannot be linked between incoming and outgoing transactions. Now we use onion encryption so basically we don't just do that once but you do that in multiple times. So basically if you pass that message through a chain of relayers that each take one onion layer of an encryption of it you have linkability that is hard to establish beyond gasoline. Why would they do that? Well, and this is an important point to me and one that makes the whole design of this network a lot harder is because they earn money for it. Who here is running a tour note? One, two, two and a half. Two and a half. So we have two and a half. Are there two and a half? How many exit notes do we have in the room? Ah, okay. Why not? Why not? I mean Switzerland. Ah, okay. I mean the question is why would you, right? There's something that comes at quite non-zero cost especially quite non-zero legal cost so why would you do it, right? So any system that runs at scale needs incentives and I think we've seen how this well just kind of works but still not very works really well for Ethereum or any sort of blockchain systems where nodes don't have incentives to run a phone out, right? So this is why we want to incentivize relayers. So basically a hopper comprises a message with a payment layer and on the message layer we use as described only encryption in the Sphinx format which I will go into in a second a bit more in detail and of course we built this on LibP2P and have a JavaScript implementation that I'll show later and we have payment channels and we will also discuss a little bit later in detail with a POC on Renkeby right now. So briefly on the message layer what's going on. We're giving a message to Dave via two hypothetical relayers their friends Bob and Charlie. So Alice is formatting a message which has a header which comprises two components one is routing information and the second one is payment information, right? And then of course there's the body which contains the only encrypted message. So what she does is she basically she defines the root so it's source rooted and she then assembles the header and sends it to Bob. Now what Bob can see in that header is so far only that Charlie is the next downstream node but what Bob is not able to do is not able to extract the payment just yet because that would allow us to be susceptible to kind of take the money and run attacks, right? So I could just take all the money out and not do anything. So Bob actually needs the collaboration of Charlie so once Charlie helps Bob he will receive a key half with which he can unblind the payment channel. And of course it could be that Charlie is just not very nice to Bob and simply doesn't do that but then Bob could basically in the future deny any traffic to Charlie. So that's of course something I mean it goes into the direction of the verifiers dilemma but we basically see with incentives you can improve that because Charlie simply won't get any payment for succeeding transaction that she denies Bob. So it continues in the same fashion Charlie takes the packet with the help of Dave she will then get her payment out and with that we basically have the cycle completed. So this is in simple terms how our message layer works like and now let's look at the payment layer. So on the payment layer what we see is that we see these kind of encrypted payments going around and we have two key halves so it's a secret sharing mechanism which we have in place there and Bob to obtain his payment Bob can derive the first key half and the second one he needs Charlie's help for and with that he can get his payment and Charlie gets her payment. Now if we look at traditional payment journal implementations we see a couple of limitations here that we are trying to improve upon. The first one is of course that we want kind of a tight coupling of the packet and the payment data and the second one is kind of a proof of relay right so we only want you to be able to extract the payment if the next downstream node has actually sent you a confirmation. What we also want is we want you to have a realistic scenario there is packet loss right things don't always go well so we need to be able to have partial payouts and with traditional payment journal implementations you see that payment journals are always set to absolute values right we don't just have delta amounts we set a payment journal to an absolute value so if I send you a transaction or if I send you a million transaction and you were only ever successfully relaying the last one of them you would still get the full payment because it sets it to the absolute value of the last transaction so that's one problem and the second one is you could say well we kind of unlock a payment on a packet by packet basis but that would be kind of a huge proof size which you would deliver to the blockchain and then what could be said is because we heard quite some things about snarks and stars and fancy crypto stuff so the goal of Harper is IoT devices on really small devices that are somewhere out there in the field in which do not have the capabilities of doing really complex computations on there that's what we tried to go for relatively simple critical here so this is a bit more in detail how this proof of relay works and to understand that I will work you once through a setting of a payment channel so our players are on the left is of course smart contract that's our payment channel smart contract and this interaction here is Bob closing his his payment channel so basically getting his money out that he got one way or another from Alice so first of all a smart contract is validating his signature over a curved point that Bob gets from Alice that's the best tool the smart contract is then also validating a pre-image of this point so basically we have this publicly known curve point kind of a pre-image here so this multiplication is an elliptic curve operation so you cannot easily invert it and it could also be as I mentioned before that partial AL should be possible so it could be that some secrets will not be that Bob will not be able to derive all pre-images so there's some parts of that which is which just failed now basically we need to where do we get all these values from what do they mean right so Alice sends kind of an updated curve point with every single packet and she signs it this is an analogy to the updated values of traditional payment channel implementations okay so we have the S total from the difference between two succeeding S totals we kind of have the delta S from which we could also assemble the S fail if something goes wrong I got a package from Alice but I can't pass it on to Charlie so I basically add that to my S fail now for the parts where things did go wrong and they go right so for successfully relayed packets Bob can derive the first key half and the second key half which means the collaboration from a downstream node so the first key half he gets himself whereas the second key half gets delivered from the next downstream node right so basically you just sum that all up and that gives you the pre-image of the you could say the secret which you deliver to the smart contract for payout right so because this one here still gets multiplied it's basically a secret that was known by Alice gets transmitted in a different form over the wire and then can be used by you and only you in order to unlock your payment so this is basically how we achieve a payout conditional to the delivery of a packet evidenced by having a key half from a downstream node and having an efficient settlement that is basically that is basically constant in effort in data overhead so we can settle that on Ethereum today cool and with that I think we are running out of time and my connection here is pretty poor so I let you check out ours okay I expected that sorry for that we have a smart contract on here you see some transactions of opening and closing payment channels and receiving a payout for your connections that I do so you can check it out and with that I am open for questions thank you very much yes so does the settlement of the payment not kind of like introducing like leak who sent what to whom yeah that's of course a good question yes of course it does leak something but it leaks kind of minimal information about what payment channels you have and kind of what you used in bulk if you would do something super stupid like you would settle on a packet by packet basis which is not even economical then yeah that would be pretty bad but what I imagine more is that you would do that on a monthly or quarterly basis so you would then say okay every month I want to take my money out and basically what we would see is that you got X out of this and you get I don't know 0.5 ETH out of it so yes it leaks some information but not more than is publicly known anyway and yeah we are working on right now is how do we incentivize people to open as many like reasonably many payment channels useful payment channels to reduce the meaningfulness of this information thank you for the talk and I actually have a bunch of questions so first one is that I know I suffer from high latency so how is the hope of the problem and second one is that recently I noted a protocol called C-Mex it's using mixing as well so I wonder if you guys had a study of that and what's the opinion of that audio computer this fall and then there's a proposal it's to use down-and-routing to prevent front-sensoring from the phone out so is there any possible that you can use the offer protocol to deal with the problem and also opinion, thank you cool, let me try to remember all these so yes basically this sort of peer-to-peer communication is certainly slower than direct communication that's clear the question is how bad and the question is how bad we want to keep customizable by the application layer so if you build a chat app like WeChat 2.0 you want some one-second latency you have kind of okay privacy so there's this fundamental trade-off between privacy and latency if you want to do some activist group emails then probably you want hardcore privacy and you need 30-minute latency so it should be possible to define that on application layer your second question on C-Mex we will need to look in the implementation details so we have a lot of ideas right now out there and not all are really implemented so it's kind of hard to tell this is by the way, it's all open source you can check it out on our github feel free and the third question yes, so right now ethereum doesn't unlike bitcoin ethereum does not support only running out of the box and yeah, that was one of the inspirations why we started to offer as well so do you think that this is going to like ethereum in the future? that's the goal, I mean for us that's the goal admittedly we're pretty early on here right so we're looking at a largely unfunded project for some donations so yeah, but that's absolutely the goal well thank you any more questions for you? do you have to open up a payment channel with every neighbor that you have or I guess with every relay like how do you how does that work and also isn't there a churn in terms of like new relays popping up and other ones going away to have to constantly be opening up new payment channels, is that how many kind of are there? yeah, so how does this work right now, right now we have a slightly optimistic scenario where we open them on demand for you which is quite easy to exploit but the idea is that you have some strategies as to what payment channels you want to open so we would actively you would actively open them we would have some default strategy that you could you could change yourself because it is right you will have some churn but also some nodes will be decent relayers and others would not be, so basically to reduce churn we are currently working on some mechanism of slashing those relayers that are offline for a too long amount of time so basically something that would be annoying is if you're in an underground and you're like offline online, offline online so you have some maximum traffic loss so that's what we want to prevent here I think we have time for one very last question otherwise we just close it here and I'm around afterwards if anybody has questions on a one-on-one basis thank you very much for your attention


Hi. So welcome. I'm going to be talking about multi-unit OpenStack deployment using LexD containers on your laptop. So hopefully, you're all in the right place. Looks like a good turnout, so thank you for coming. OK, so who am I? My name's James Page. I work for Canonical, and I've been technical architect on the OpenStack team for the last 18 months or so. My background in OpenStack in Ubuntu is over the last six years. I remember it right from its infancy to where it's got today. I've been working in open source technology for about the last 15 years. Debbie and developer, Ubuntu Core Dev, an OpenStack contributor. And the OpenStack engineering team at Canonical are responsible for the packaging you all use on Ubuntu, the deployment tooling we have around that, which I will touch on today, and the testing and putting that all together as part of our release every six months. OK, so the first thing I'm going to talk about is OpenStack is hard. So such a plethora of different services, performing different functions to orchestrate an infrastructure-as-a-service cloud, it becomes very difficult to put together. Some of you may recognize this picture. It's been around for a while.  It's really, really hard to put together an OpenStack cloud. It's very easy to follow the upstream documentation if you've got the willpower to get through the many hours that may take you and do it by hand. But you only really want to do that once just to learn how it all plugs together. And then it becomes, you have the requirement to have a repeatable process to then start doing that. So it means that when you start deploying a cloud for the first time, you have a question as to how are we going to do this? How are we going to make sure that what we put down today, if we need to expand it, that works. If we need to redeploy it in a different location, that works. How do we make sure that all plugs together? So I'm going to take a little bit of time to talk about the service modeling tool we use at Canonical for putting down clouds. And I'm going to talk about containers, and then I'll talk about putting that all together. So you are in the right place still, don't worry. Gigi is the service modeling tool we've been working on at Canonical for probably about the last five years. It allows us to deploy services, scale them out, integrate them together. Relations between services are very easy to model. And we can use all those concepts and then put them down on different providers. So on bare metal, on top of clouds, such as OpenStack for things you want to deploy on top of it. Or in containers, which is the topic of this talk. So for the bare metal, this is how we put down OpenStack itself. We use a tool called MAS, Metal as a Service, and we can deploy using Gigi and the Charms, which encapsulate each component of OpenStack, an entire OpenStack cloud on hardware. We also combine containers into that to make sure your control plane is nicely segregated from the underlying physical resources and from each other. So Neutron and Nova and Cinder are all in different containers within that deployment. But I'm not going to talk about that too much today because I want to get on to the stuff I've been working on to make this all happen on your laptop. So this is what an OpenStack model looks like in Gigi. All the various different components, dashboard, database, messaging. I've got some Seth in there as well for block storage. We can apply things like NTP on top of that to make sure we have consistent time, that sort of thing. And all the relations between them, we can encapsulate this in a model and then we can take that and deploy it onto hardware. But how do we condense a cloud? How do we take all those things that we find great and use every day to deploy on our server hardware? How do we take that and do it on a laptop? How do we take all those modeling concepts that we like and test them on a regular basis? So that's what I'm going to talk about next. So I'm going to dive in and talk about LexD for a little bit, which is the underlying container technology that I've used to put this together. So LexD is a pure container hypervisor. It gives us the ability to do very dense and very performant full system containers for Linux guests. So don't try and use Windows in a LexD container. It doesn't work. You're getting direct access to the Linux kernel that the host is running and it's a containerized set of processes on top of that. Dig into that a little bit of how that's different to an application container in a second. So LexD is a project that's been around for about 12 months, maybe a little bit over that. I think we named it in Paris and it's been in development ever since then. LexD is a kind of ground-up redesign around the user experience for managing Linux system containers. So you may have heard of the word LexD before and that was the group of technologies to manage Linux system containers on Ubuntu and Red Hat and all of the Linux disk drives have really adopted that. But LexD was an opportunity to kind of reflect on the work that had been done in LexD and think about how to design the command line UI, how to put a REST API on top of this to make it very consumable both for people and for other tools. So things like Juju, OpenStack, that sort of stuff. So it's got a lovely simple REST API. It's designed from the ground up to be very, very simple to use. It's designed to be fast. We all expect that a container spin-up is fast. So LexD is fast. We haven't reinvented the wheel in terms of storage backends and stuff like that. So we're leveraging a lot of other mature technologies. So a lot of the overhead of creating container is not starting the process. This is actually creating the file system image that you're gonna run underneath the container. So we've leveraged fast storage backends with copy and write features such as ZFS, the LVM and ButterFS to make that spin-up of a container very, very fast. So we essentially goal copy the image and then each container then uses that image. Starts up pretty quick and I'll demo that shortly. LexD designed to be secure. So we took that approach. LexD containers have developed the required security features over the last six years to make it a real story. So a LexD managed container is by default an unprivileged container. So that means the processes in it are not running as root on the host OS. So they're running as a sub UID range of an unprivileged user. That means if you did have a container breakout, all that breakout exposes on the host is an unprivileged user. So yeah, it's still a problem and we don't want that to happen. So we also wrap our containers in app armor which means that the processes within the container only have access to certain paths on the host OS. They can only perform certain operations that we allow them to configure. So network interfaces, parts of the file system, that sort of thing are all restricted in that way. LexD self, in terms of its API, we use TLS encryption through and through on the network connectivity to the rest API with client certificates for authentication. So again, we just used a whole load of an existing technologies to secure the product well. LexD, if you're interested, is written in Go. We've been heavy users of Go since we took the decision to make, right, juju in Go about three years ago and it's worked very well for this project as well. So what is LexD not? LexD is not about application containers. We're not trying to compete here with Docker or Rocket which are very much about containerizing a single process using those same base Linux technologies and managing those at scale. On the other end of that, we've got all of the hypervisors we know well. So Hyper-V KVM and this is where LexD plays. It's about full system containers, machines you can log into. They've got SSH, they've got Syslog, they've got CRON. They've got all the things you would expect from a server install or a KVM instance. So you can use all your existing tooling to manage them but you've got all the benefits of container. So you're next to the metal, you're getting bare metal level performance. You've got high density on that as well because the overhead of each container is very, very minimal. Okay, so I'll just give you a quick demo of LexD itself. Let's see how I get the right monitor going. One second, I'm having a multi-display disaster now. We should get there in a second. Okay, let me just increase the font on that so you can actually see it a bit. So this is the LexD command line API. So this is interacting with the demon via local unit socket using the rest API but you can equally manage remote LexD demon in the same way using the TLS transport. So I'm gonna show you that I've got a few images loaded in here so I've got a trusty and a zennial image. So LexD provides a number of ways to get images in. LexD image is typically a root table. It's not a Q-Cal too. So it's a different image format to what you'd be familiar with with KVM. On this system, and this is all on my laptop, I've got ZFS configured on half the SSD. So ZFS is a feature of our 16.04 release because you very fast perform and copy on right clone. So it makes a perfect partner to LexD in terms of how we manage the underlying storage for containers. You can see I've got a load running. I pre-deployed my open stack. It was not enough network in the room to do it but we'll get into that in a minute. So if I wanna launch a container, it's stable. So ButterFS had a lot of the same features but I think a lot of people have been burnt by ButterFS and its stability and production grade redness seems to be variable in people's opinions. ZFS has a slightly different semantics. So it's more of a combined LVM and storage fast system. Can I actually just part the question till the end and then so we can get through the content first. Thank you. So I'm gonna launch a Zennial container. It should take about two and a half seconds and I'm just gonna hop into that so you can see. The exact command is allows the someone on the local or remote system to get a shell directly into that container. Again, it's secured via the authentication that the client's providing. So you can drop in and you can see instantly that we've got in it. This is actually a system-based container so we can do the normal operations you'd expect so we can see SSH is running. We can see the operate within the container in a normal view. So that's like Steve very quickly. It's very easy to install if you wanna try it. 16.04 works out the box. Okay, wire project is never easy. Okay, so what I'm gonna talk about next is how we've plugged Juju together with LexD in our 2.0 release of Juju to allow you to deploy Juju services on containers on your laptop. So this is a feature we've actually had for a while. It used to use LexD, the base primitive rather than the demon on top and it allows you to deploy those Juju models and charms on into LexD containers on your laptop. So as I said before, this is all completely functional in 16.04. You can run it on 14.04 but there's a lot more hoops to jump through in terms of kernel versions and back ports and stuff like that. So if you wanna try it, I tried on 16.04. As I said, I'm using ZFS as my storage backend. You also have LVM and ButterFS and if you don't have a dedicated block device to do that on, you can do it using a sparse file directly managed by ZFS on top of your 64 file system if that's on your route. That works fine. It's pretty performant and gives people an instant bootstrap. I'm running some of my laptop. I can run a whole cloud on an i5 with 16 gig of RAM and about 200 gig SSD entitled. It doesn't need much more than about 50 for the actual cloud. So, we did dive on a couple of little features that we've used to make this. So as I said that LexD containers by default are secure, they're unprivileged. They have limited access to devices on the host but mostly also has the capability to expose more things to a particular container. It does that for a thing called a profile. So that can map devices from the host directly into the container. It can give it additional security permissions like being able to do nested network namespaces, that sort of thing and that's then controlled by our app armor in terms of the permissions it has. We can give it extra network interfaces so we can map a container into multiple bridges on the host so that we can have multiple network ports in our underlying containers. And that's hotplugable as well. So you can apply that to a running container and get additional network interfaces. And we'll drop into that. I said I don't wanna risk the monitor again. Once we get into the demo, I'll show you a profile. And we've got a particular bundle. So a bundle is a group of charms, the configuration of them and the relations between them. It's up on GitHub and the URL at the end of the presentation if you wanna go and take a look and some good documentation there as well. But a bundle is, we have an open stack on XD bundle which has got all the right config knobs tuned to allow you to do this. Okay, so let's have a look at the cloud I've got running. Okay, so just start with Juju. So this is the command line interface to Juju. Juju has a GUI which is, as of 2.0, is baked into the core product. So as you bootstrap an environment, you can access the GUI. It also has a command line interface. So for those of you who like to live on the CLI, rather than for a web UI, this is perfect. Or in fact, it exposes more of the features of Juju than the GUI does. The GUI is designed to be an abstraction on top of that with an ICN. I will show you that in a minute. But this is the open stack deployment we've got. Now I've trimmed down the number of services purely because I wanted to squeeze it in on this laptop. So we've got the core infrastructure services, Cinder, Glance, Keystone, Neutron, and Nova, and the dashboard as well. I haven't put Swift in. Requires quite a number of containers and was just a little bit more than my laptop could manage, but it is possible to do that. So we're using a Ceph storage backend, which is managed purely through the file system, so no requirement for block devices. And we're using the Radius Gateway just to provide some basic object storage services on top of that instead. We've also got MySQL and RabbitMQ deploy to provide all the core infrastructure services for all those components. So if we look at the actual cloud itself, typing and looking is hard, isn't it? So we've actually just got a single compute node so we can query the kind of status of the agents and stuff like that. And you can see the Neutron agent. So we're running a network node as well to provide the North-South traffic routing. So we're able to fully use overlay networks as part of the container story as well. So this is actually running GRE, but VxLan works fine. And then we have what we call our Neutron gateway node, which is a network node, which then provides a North-South traffic routing and floating IP access to instances. So I have to admit I've already preloaded a image and configured a couple of networks. So we've got the underlying external network which maps onto the IP configuration of the bridge on the host. And that's shared with the DHCP range for the lexi containers itself, although that could be a separate bridge if you wanted to do it that way. And I've also got an internal GRE network setup as well. So let me try and find that one as well. So what I said is that there's a GUI view of juju as well. This is the same view of the model that I got running on my laptop, but viewed through the GUI instead. So you can, again, you can see the various different components here, RabbitMQ, we've got the Sephrados gateway and Sep itself and then all of the Cinder components. So these are running in its own container and juju provides the relation semantics for those things to communicate with each other during configuration, set up things like user names, passwords, that sort of stuff. So I've been able to use exactly what we do for physical hardware to deploy that onto my laptop. So just to prove this isn't all neat trick and it doesn't actually work, we'll log on to the dashboard. So if we have a quick look at the hypervisors first, we'll see that there is an acutely hypervisor. So this is going to run a KVM instance and we'll hop in and launch an instance. Let's get rid of that. So I'm going to boot it from the Xenial image that we saw on the glance image output a minute ago, just using the FAML storage root. Give it, make it an M1 small, add it an internal network connection. We don't worry about network groups or security groups in moments. I've got to keep our loader as well just so we can access it afterwards. And that should be enough to give us a running instance in a container on my laptop. I think it's crossed. It worked 30 minutes ago, it should work now. So the way we've been able to do this is we have Livevert running inside the container. We've exposed the host devices that Livevert and OpenV switch need to be able to communicate with the kernel via a profile into the container. So, slashdevkvm slash devtunnet and slashdevmem are all things that those particular things need to use to be able to manage either the networking or the state of the instance directly. And we've got a running instance. Just check the console log, make sure we've got some networking. I don't know whether you can even see that. There we go. The instance spun up, it's got an IP address from the internal network range bar from the DHCP services running on the network node, which is on a different unit container to the one running the load compute instance and it's fully booted. So, I will just drop onto the command line again and we're just gonna have a look at exactly what that looks like under the hood. So, if you've ever logged on to an OpenStack hypervisor, you probably run this command. So you can see here on the internal bridge we've got the connection to the KVM instance and we've got on the internal bridge, we've got the tunnel link out to the network node to provide north-south traffic routing and DHCP services, that's metadata services as well. And you will see exactly the same view, so I can, same familiar tools, so if you wanna look at the actual instance, I can see there's a running instance from inside the container. And we'll now try and access that. So, I'll flip back to dashboard for a second. I'm gonna give it a floating IP because it's just on a private network at the moment. Okay, so we now have a floating IP associated with it, so that's 10, 20, 100.1. Ah, I remember, I didn't add any security rules to actually access that. So, let's just go and do that now. To show you that all the features you get on a normal hypervisor, you do get in containers as well. So, we'll add some SSH connectivity. I've already used this IP before, one second. Okay, so this is the KVM instance that we got running on the cloud. So, demonstrated we were able to deploy it in containers, we can spin up instances, we can network them effectively, we can do overlays, we can do north-south traffic routing, we can apply security group rules, all the things you'd expect to be able to do on hardware. I've been able to model accurately in containers on my laptop. You can also create block devices in Cinder, we can present those to the instances and simulate storage in exactly the same way. Okay, so if you're deploying an OpenStack Cloud, you'll probably have testing and production environments at a server-based, because you wanna be able to validate changes you're making into the environment, changes you're making into deployment tools, OpenStack upgrades, the number of things that you need to be able to verify. So, where does this type of concept fit in nicely? Well, it starts to allow you to make the laptop your first touch point on a change into your environment. So, you can take that same bundle, you can redux it from your laptop, you can try a different configuration option, you can try a different topology, you can add some new components, you can verify that on your laptop. It takes about 15 minutes to stack a cloud this way. So, the teardown cycle's pretty fast, if you need to change that, iterate that. And then you can then take that forward into testing on servers where your deployment time's probably gonna be longer because servers take a long time to boot for a container, there's no post, nothing, no kernel to even boot. So, the container bring up time is very, very fast. So, allows you to bring your laptop in on the front of the changes you're making into your environment. So, for people who are first touching on OpenStack, means they don't have to find five servers to try this stuff on to start off with. They can try this on their laptop today, just using the tools that Ubuntu 16.04 is shipping with. So, I demonstrated KVM cloud, we also in 16.04 have a driver for managing instances on your cloud using the LexD hypervisor as well, Nova LexD, that's not entry in Nova yet, that's a project we've been running under the LexD projects as part of the activity around LexD. But it does allow you to use a container in your cloud as well. So, alongside KVM you can have LexD containers with consistent networking and all the things you need to be able to mix those two things together. You can also run LexD in LexD. So, we can then nest that and put that all together and try it on your laptop as well. So, in the Git repo we've got, we've got a bundle that does LexD rather than KVM. So, if you wanna try that out, you can try that out as well. Another project we've been working on is a tool called ConjureUp. Used to be called the OpenStack installer which was really boring and very specific. It actually kinda turned out to be a bit more generic as a tool for taking deployment bundles, using Juju to then deploy those both in containers, in a single machine or using Mars onto multiple machines. So, in 1604 there's a tool called ConjureUp and you can ConjureUp OpenStack and that will allow you to try this. It will also allow you if you have Mars set up and some spare servers to deploy an OpenStack cloud a little bit more easily onto that as well. I think you can also ConjureUp big data if you like that sort of thing. So, it's designed as a generic framework for taking bundles and then driving placement of those across either containers for testing or for onto physical server infrastructure as you take that into more rigorous testing and into production. Okay, so we've got about 10 minutes left. So, if anyone's got any questions, please use the microphones and then they get on the recording as well. Hi, talked about the pros. I wanna know what's the cons of running OpenStack components in LXD, is there any? Sorry? Is there any con for that? Like, what's the disadvantages of that? Well, you probably wouldn't run necessarily this in everything under containers in your production environment. So, compute nodes are typically gonna go onto hardware rather than into containers on hardware. So, this is a great way of not trashing your laptop by installing OpenStack on it. And, as a result, it gives you a nice encapsulation of the thing you're trying to test rather than you having to do that all on the thing you're actually sitting on. And you can throw this away and you've got no more state left of what you just tested. So, that's the pro. Cons, I don't know, for the context, I think it's pretty cool, so. I have two questions. One, you showed kind of putting your laptop in front of your dev process and making out the first stop for changes. Can you, I assume, you're deployed everything from move on to packages? Is it possible to incorporate this into a developer workflow where you're testing patches from source? Yeah, so, this is deployed from packages. So, it's the result of development rather than part of development. The charms for deploying OpenStack on Juju do support deployment from source as well. So, we have the ability to take OpenStack projects and instead of using our binary packages, pull those in and deploy from Git repositories with appropriate requirements and pip install dependencies and stuff like that. So, we're kind of thinking along those lines yet. There's some features that I'd really like to see land in an XD before we can make that reality. I'd really love to be able to bind mount the Git repos I'm working on locally directly into my containers for my branches and install from that and then have a nice iteration cycle where I make a change, rebase, whatever it might be, reload my deployed containers and retest everything. So, the answer is, yeah, and that's kind of where we'd like to go but we're not quite there yet, so. And then second question, you mentioned the profiles. Yeah. So, you have a special profile from over at Compute so it can talk to the kernel. Is that described in the charm metadata somehow or is that some manual thing that you do after you've deployed the containers? For this demo, I pre-created the profile that Juju was gonna use because I know what its name's gonna be because it's Juju default. It's the standard model that Juju 2.0 creates. We're talking with the Juju team at the moment as to how you might express a profile as part of the charm to allow you to do that in a more automated way. And then that can then be applied on a service by service level rather than at the entire model level which is where we are today, so. So, going back to the LUXD within LUXD, there's been talk about the Nova LUXD driver, essentially. Has that been implemented with all the Juju and kind of an integrated environment? Yeah, yeah. So, the Nova Compute charm, which is a principle charm for managing the hypervisor, supports LexD as of this release of the charms which came out last Thursday. We have another charm which is called LexD which does all the underlying management of storage configuration and the actual underlying LexD daemon as part of that tool. So, it's basically you add two charms to the bundle and you can do both in one. So, kind of leading into this is where I'm really actually interested is using LUXD as a test bed. I would like to be able to test basically a multi-node open stack environment that is mixed mode KBM and LUXD hypervisors. And how it works. It's entirely possible, yeah, so. So, is that basically us using hypervisor types and delegating some computes as KBM and other. Exactly right. So, by tagging up the images with appropriate hypervisor type metadata, the image properties filter will then schedule those onto the right underlying hypervisor. So, determining the hypervisors based on the image type and not by some other. Yeah, I mean we're fortunate that LexD and KBM use quite different image types. So, it's a very clear boundary there. I think it's also possible to do using different flavors with additional extra specs as well. So, there's kind of two roots there. But the combination of just picking an image and picking a flavor means that the flavors are consistent across any underlying hypervisor which makes that a quite a neat story. I actually talked about this yesterday. So, check that one out as well. Okay, looks like there's no more questions. If anybody wants to talk to me afterwards, I'll be around for the next 10 minutes or so and thank you for listening. Thank you.


What's up, everyone? It's your girl, Kenzie here from Leighton Sports Cards, and I'm ripping a personal for Gary A. We've got two 2022 Topps Chrome Sonic baseball light boxes. Good luck, Gary. Thanks as always for hopping in. Let's see an auto. We didn't get flooded here in Central Florida Gucci. It's going pretty good today so far. I've been ripping some nice products, pulling some nice cards. Ricky Refractor of Zach Lothar. Prism, Fraser. Stevenson, John Meebs, McNeil, Ricky. First way rave up, it's going to be a rookie of Zach Thompson. Pirates. Zach Thompson, Glad Thompson, Bobby Daubeck Refractor, Eli Morgan, Ricky. Refractor Joey Gallo, Connor Wong, Ricky. Ashby, Ricky. Refractor Gabriel Arias, Youthquake, Hendricks. Seth B. Rookie, Prism, Nico Horner. Way Rave is a Trevor Larnack. Half here, Jake Berger Rookie. We've got a Sonic Pulse on the purple and yellow. That's 274 of 299, Cabrion Hayes. Nice looking card there. Cabrion Hayes, India Cup, Heal Rookie, Durand Rookie, Lendor, and Schroentz. Got Refractor Swanson, Prism, Starling Marte, Lowe, and a Ryan Zimmerman. Way Rave. Getting all you got forced tonight for a group rakes. Worker, Refractor Joe Ryan. Rowanzee, Contreras, Youthquake, Rookie, and Manoa. He'll be starting at five tonight. He's got hockey, soccer, and then getting into baseball, basketball, and football. Ending with a Sunday-funded 25-box break. Tremend, see any way rave of football. Nice, nice line up there. It's got a 2020 honors and 2020 iMac. So some nice, nice boxes coming out of there. Mullins, Kearlaw, Pavin Smith, and Justin Turner. All right, that will do it for the first box there for you, Gary. Let's see what we can get out of box number two. And after Gary, you've got Brett W. and Jaren S. That is the current queue. Only two people in queue after this. Oh, about a 20-minute queue or so. He's Muller and Vado. You know, Brett has a generous football, and I think Jaren had a few right, not Castle Refractor archives. So not a long wait at all. Mandas, Dettmers, Jackson, Wisdom, way rave of Mike Yastremsky. Refractor Rookie of Bruhan for the race. Gin Rue, O'Neill Cruz, Rookie Base. They've got you, Darvish Refractor and Marcus. Lams, Manaya, Musgrove. I am not sure, Brandon. Prism, Tyler Stevenson. You're not on the way rave. I'd have to look at the release calendar and that's not even set in date because stuff gets pushed all the time. Green way rave is going to be in a manual class A. That is 31 of 99 guardians. It's green way rave there for you, you know, Gary, Alex Ball. Prism, Miggy Cabrera, Correa. In your ver refractor, Kyle Hendricks, George Kirby, Youthquake. Way rave, Michael Brantley, Zach Short, Buster Posey, Traris, Moncada. Got another sonic pulse. It's going to be a Corey Seeger for the Rangers. 283 of 2.99 on this one. Glass, no? Neal, Rookie Refractor, Trey Ambergine. Kowar and a Lars Newpaw Rookie way rave. All right. Last pack here for you, Gary. For you, Laurie Schwarber and John Lester. Alrighty, that will do it for your boxes there, Gary. Thanks as always so much for hopping in. Always a great time ripping for you, man. We'll get these right up to you.


int, us having an interest in our children's online lives. If my child goes to school every day when they come home, I ask them how their day was at school. I have to say that my kids don't tell me very much when I ask them that. We also know that our kids spend an incredible amount of time online. Do we know who they're spending time with? Do we sit down and play games with them? Do we have a curiosity about their online lives? I think that the discourse that we have around online safety has, unfortunately, sometimes been defined by people with tech backgrounds. There's a discourse about how we make sure that we have the right restrictions on devices. That stuff is really important, but picking up an Alison's point from early on right at the start of this afternoon, the answer is impart relational. There's a discourse about how we make sure that parents are actively thinking about gap-keeping, supervision and monitoring of young people's online walls as they do with offline walls. I'm going to say absolutely, but further to that, Joanne pointed out earlier, that not all of our children have a reliable or trusted adult caring for them, who will take that approach with them. That's when we would be looking for the likes of youth workers, educational staff and they also need to apply that relational approach. I think that there are nuances, but I would agree with Stuart that they're broadly the same. Maybe we're missing a trick in terms of the legislative definition of what would constitute a crime, but what is the impact on children? That's maybe what we need to come back to when we're thinking about definitions, and actually I was thinking about yourself, Gina, in terms of maybe children would be better to tell us what a working definition of that would be rather than us as adults. I think that as adults we probably understand what we mean by online exploitation and abuse. I think that the difficulty is, and Stuart highlighted earlier, there are so many different strands to this.  We have online exploitation as a part of that, so it's how do we bring that all together? How do we make sense of that? If we're going to start this discourse with children in relation to peer support and peer education, what does that mean to them and how do we make sense of that? How do they help us to make sense of it in a way that we can have these conversations meaningfully? I was listening intently. I'm quite interested in this. I suppose my view is that in terms of my officers and staff going out and dealing with children and looking at fences and working out which parts of the law fit with what we've got, I think I can hand on heartsay that that bit almost comes later. For me, I agree with Stuart around that. I think sometimes the definitions doesn't matter. If you've got a young person or a child in front of you and there's been a report of some sort of abuse and something's not right and you know that, I think actually talking to that child and listening to their experience and their journey, you understand what's happened and you use the legislation around further down the line to understand what that looks like in a criminal context, but actually the most important bit is listening to the child and understanding, making sure they're safe, I suppose. So I think policing's changed a lot in the last few years around that. I think our focus would have been much more around a criminal justice outcome, but I can absolutely hand on heartsay that now the voice of the child and the experience of the child and the safety of the child is key, and if that doesn't result in a criminal justice outcome because it doesn't quite fit in terms of a legislative outcome, then I think as long as that young person or child is protected, that's what we would say as a success. I think that's a real culture change in law enforcement, so for me, in a long-winded way, I don't think the definition is important. Yes, there are gaps and there are loopholes in the definition that we have at the moment in terms of things that we could close to make things easier, but in terms of a definition, I would say most professionals will work around listening and understanding to the child, and then the legislative side of it comes a bit later on, is my sort of sense and view. Thank you very much. I think that Audre would like to come in, followed by Jamie Greene. Thanks very much, convener. I'd like to just go back, if I may, to the discussion at the start of the meeting. You're self-community picked up on the issue of resources, and I know that that is an issue that we've looked at in committee previously during a session with Police Scotland and the NCA, and miles you were involved in that. We've also looked at that in our pre-budget scrutiny, so recognising that part of the overall response to child sexual exploitation online is one of enforcement. In terms of making sure that we have that bill's body, if you like, that is able to undertake that investigative role, given the international dimension and the sort of underground dimension of it. I'm still not totally clear what we need to be thinking about as committee members and also from the perspective of the Scottish Government, and I'll maybe ask Miles first of all, and then maybe hand over to Bex. What skills do we need to be recruiting and thinking about in terms of filling the skills gap, to ensure that we have an investigative capability? Secondly, how do we make Police Scotland almost an employer of choice and not Google when it comes to attracting that skills body into the workplace? I'll maybe ask Miles first of all. Thanks. We should be really clear that our assessment is that the threat continues to grow, the complexity continues to grow and the severity of offending continues to grow. The challenge is really out there for us. It's really important for us and I'm sure Bex will agree that what we need to do between the national crime agency and Police Scotland is have a good line of delineation demarcation around what the NGA can do and should do, what Police Scotland can do, so that we work efficiently and effectively as a law enforcement system to protect the people of Scotland. We're very clear in our agreement with Police Scotland that what Police Scotland wants us to do and what we will do is to do the things that you only really want to do once. You only really want to have one international liaison network and have one set of strategic relationships with international partners law enforcement wise. You only really want to have one set of national security capabilities that are technical things for doing stuff on the internet. You only really want to have one strategic assessment that you work together on and so we're very clear that we have a delineation of capabilities and capacity to do that and Police Scotland has a direct call into that capability. In terms of the skills and capabilities to do that, what we rely on being public services is the mission and the vocational pull of protecting the public in this particular space and that really does work for us very well. I'll be absolutely transparent and frank with you that it is difficult to retain our colleagues, particularly those colleagues with social work experience because of their retention allowances and the comparative pay, but we are very keen to attract the right skills to retain those right skills by giving colleagues the opportunities to do things within the NCA within law enforcement that they can't do elsewhere by reinforcing the importance of the mission and how important it is to protect the public. It's really clear that our investigative doctrine, particularly in this area, is starting off from protecting the child and the first thing we want to do is to get to the position where we've got actionable intelligence in order to protect the child and have that child focused element to it. Being focused on a mission and making that clear to our people and treating our people well, that's their wellbeing and looking after our people. That's really important to us and I think probably Bex will reflect that in the work of Police Scotland as well. Thank you. From a Police Scotland perspective, it's a really interesting question and law enforcement has always struggled with recruiting experts in the digital space because of the pay structures that we operate in and you will understand that. I think Police Scotland's done under the cyber strategy has looked at actually can we bring people in who have got the skillsets that we need and have them for a period of time where we train them, we invest in them with the knowledge that perhaps they're going to leave the organisation and go on and work in different places and I think we've got to be a realist in this space. We're not going to be able to retain talent in the digital space for more than a couple of years. People will go off and they'll earn more money in different jobs and they'll move around and we know that from patterns of young people, the way they work these days. Policing is no longer a 30-year career and I think that absolutely fits with the cyberspace. We are looking at utilising young people, we're looking at going out to universities, using academia, bringing people in in short-term contracts to be able to focus on specific pieces of work so that actually in the cyberspace we can utilise their talent and their skills and then understand that they will walk out the door and we'll have to bring in new people. So it's a different way for us for recruiting, for retaining staff in that area but we're alive to that, we understand that. We're looking at also using ethical hackers, people that have a real sort of strong moral sense of purpose around this and actually Miles hit the knell on the head when he said a lot of people come and work with us for a period of time because actually they want to make a difference, they want to feel like they're getting out of bed to do something that really means something to society and ultimately that's what we capitalise on. We bring them in, we can offer them different types of training, we can show them different skills that they won't get in the private sector, especially working with the NCA, that's really important for us. So that's the path that we're going down. It's a long road, it's going to take a while to be in the space where we can say we're really happy with the number and amount of people that we've got working in that area but we're definitely on the right track and I think that will only improve moving forward. It's a really good question and absolutely one that we're considering definitely. Thanks very much, that's really helpful. If I may just come back on a quick follow-up and it's maybe one for yourself Bex and that's in relation to the welfare of not just officers but staff who are involved in the investigation of often complex and quite harrowing inquiries. Just before this roundtable, we were discussing policing and mental health in our first roundtable of the day and so I'm just interested in what provision you were able to make or you have in place to ensure that the welfare of officers and staff who are involved in investigating cases of child sexual exploitation is monitored and supported. The wellbeing of staff generally is a massive thing for me and for Police Scotland. We know and I from personal experience have worked in the child protection arena for a number of years and know how difficult it is sometimes to switch off when you get home and the impact it can have on your friends and family can be really tough especially when you feel like you're trying to make a difference and somehow you're not sure you're doing that when you look at the volume of work that we deal with. For me personally and in terms of Police Scotland, this is a real commitment that we're making to the point where around the public protection review we're looking at wellbeing and coming up with a completely different way of looking at it across the department in terms of a new strategic plan and then underneath that within each area we're looking at kind of how can we support officers and staff so we have the psychological assessments, we have the trim process that you'll probably be aware of and I think ACC Hawkins gave evidence about that earlier but for me it's also about looking at the demand of those officers so what are we currently asking them to do, what's their workload like and the public protection review has a big strand around that so I want to be in a position where I can hand on heart say that I've got the right officers with the right skills with the right workload demand on them so that they're not under the significant pressure that they feel working in that area could have consequences for them in terms of their mental health and how they feel at home so all of that work is linked together under me in terms of a strategic board so that I can understand the workloads, the pressure, the psychological support that we're putting in place moving forward we're not there we're getting there it's a work in progress and it's something that I'm I'm really really keen to push forward on so I think I can probably reassure you that absolutely it's a real priority for me and it's definitely something that I'm looking at hence why it's a really important strand in the public protection review that we're currently doing thank you thanks very much thank you thank you I think we've got time for a very brief question from jimmy green thank you okay I had lots of questions but everyone's used up my time so thanks can I ask a slightly left field one have we seen a rise in vigilante behaviour in terms of either online or physical approaches from members of the public trying to either in capture or tackle or deal with for want of a better word predators people self-policing this in effect and if so what has been done to tackle or prevent that sort of activity yeah so I am I don't have the statistics in terms of that specific crime type to be able to sit here and tell you whether we've had an increase in that my sense is probably I can I can get that information and get that to you if that's something that you're interested in we are absolutely alive to the fact that there are vigilante groups operating and in fact recently I know that there's some covert there was some covert work ongoing in that space to understand what that looked like I think what I can say is that actually it's really important that we understand that so that we can protect people because sometimes mistaken identity can be a real problem in that in that area and we wouldn't want to be in a position where member of the public gets harmed because they're mistaken for somebody who has a sexual interest in children so in fact we had something similar a couple of weeks ago where that was the case and we reacted really quickly in terms of protecting and then putting out some really strong messaging around you know that this is not right this person has not done what you think they've done so I think from a public reassurance point of view we will absolutely do that I there is work on going in the in the cyberspace to look at that in terms of what sort of a problem we have as to the nature and scared of that in Scotland currently I don't have that to hand but I can get that for you definitely but it is something that we are aware of and looking at moving forward definitely thank you I just thought I'd raise it it's a slightly different area of questioning but also I wanted to ask the NC one final question that's around the complexity of the enforcement landscape and by that I mean you know if for example an image is discovered on a site or through an app whether that's mobile or fixed base isp access it's perhaps not often clear who's responsibility is in terms of the escalation whether it's the website operator where it's the internet service provider whether that's then governed by off-com or the internet watch foundation or ministers or police or the nca to the point of where no action has been taken you know it's not obvious always always clear to the consumer necessarily how to escalate these things and other than in the first instance where you can report something in the immediacy but then perhaps no action is taken thereafter and it's not an obvious path to escalate the responsibility of how the provider or the website is held to account and I appreciate that's crossing a whole range of policing devolved and reserved matters but do you think there could be a little bit more tidying up of the pathway so that people know exactly who does what who regulates what and what what can and will be done if no one else takes action so in in a with an eye on the clock I'll keep this very it's a very very complex cross-use addiction issue very simple and just say yes that could we could do more in that space and I think we said in my earlier response that we are very clear that we feel industry can do more in this space but I think what provides us the the the opportunity here is to see things very simply and so across policing and that's a culture change that Bex was referring to that's been brought about by working together across an entire system we're very clear that it's about protecting the child and put the child interests first that makes it very simple for us it doesn't really matter where that image is and where that's being reported or how that's being reported what we're looking at is the severity of the offending the complexity of that offending the scale it offending and therefore you know who is best placed to protect that child and and take the take the action and so that makes it quite clear for us and I do think that part of the increase in reports that we've seen it is about us working more efficiently together with industry law enforcement in Seattle in Police Scotland to see more reports because we worked together in a more efficient way thank you very much I just say quickly that you're absolutely right it is a huge kind of great area and we do need to see that tightened up and in our asks to the UK government through the online safety bill we are calling for. I mean it's to make sure that senior managers and in-scope services hold liability for where there has been a failure on the company's part because too often it's about sidestep and the responsibility so we do need a clear line of responsibility and we think that the online bill may provide the vehicle for that but we just want to finish on the point that alongside that we really need to see much more emphasis on prevention of harem and that is about a concerted coherent bringing together of all agencies in Scotland to make sure that we are identifying risk early and preventing unnecessary harem thank you very much now unfortunately we're out of time but it's worth putting on the record that we expect to look at legislative consent issues in the online safety bill in the middle of next month and I want to conclude also by thanking everyone who gave evidence and if they feel there's anything that they have not touched on and they want to expand on in any way please do so to the committee in writing and we'll now have a five minute suspension to allow the witnesses to leave so thank you again the next agenda item is consideration of a statutory instrument which is the Scottish fire and rescue service brackets framework order 2022 ssi 2022 forward slash 119 and refer members to paper five and ask members if they've got any comments they wish to make otherwise we will consider the ssi as coming into force and jimmy greenwood thank you convener so my understanding is that this instrument allows the government to introduce its framework document setting out the priorities and objectives for the Scottish fire and rescue service as it is required to do subject to the 2005 act following centralisation I have a question I guess and that's the framework document was originally published and then subject to consultation which received a number of responses can I ask if the and it's unclear from the papers if the framework document that the fire and rescue service itself will then be mandated to deliver on in terms of its priorities and objectives is the same as that which was published prior to consultation or if the framework document setting out those objectives has changed or altered in any way subject to the responses in the consultation and the reason I mention it is because some of the measures that it had been suggesting to explore new ways of how the fire service should work were not entirely positively received by some who responded to the consultation so I wonder if the government has reacted or responded to into those responses and therefore produced the document in line with the feedback it received through the consultation otherwise the consultation is pointless and that's a question for the government I push it as no government minister here due to the nature of the instrument but it's a question that I would ask the government had we been able to thank you for that yeah I'm advised by the clerks that we don't know the specific answer to that but we can seek to get an answer from the government and perhaps also input from Scottish fire and rescue sorry no thank you specifically the main protagonist to respond to the consultation and if they're happy with the framework as we have been asked to pass it or if they have any observations reservations etc that they may wish to take into consideration before the instrument passes okay thank you in which case is that something that can follow that yep okay thank you and that therefore completes our consideration of the SSI now the next act of an agenda is in relation to our visit to the wise group last week I refer members to paper number six and I'd like to put on record our sincere thanks to the wise group for hosting us and telling us about the important work they do I personally found it incredibly interesting I'd like to just open up to other members about what they took from it or any observations so Pauline yep yeah I'd like to endorse what you said convener it was a really fascinating visit which learned a great deal I'd written to convener or do you nickel just to the three points that came out of the group discussion which I do think the committee should take further I remember two of them one was prescriptions that weren't available on release which meant that particularly if there were drugs for for for people who needed them immediately it seemed to me that they could have almost put them back in jail again because they couldn't get them on on time and the second one was Friday release which has always been an issue but why can't we do something about that to make sure people have either got the services or like to explore is another way around that third one maybe someone could remind me what the third issue was one what it was eligibility for for work it just seemed like these are common sense things that we could maybe write to the minister about and see if there's a way forward yeah indeed I think in respect of the first point there's a letter in hand to the sps about that issue of prescriptions the second point I think Stephen can address thank you thank you convener thank you convener so yeah in terms of your other two points Ms McNeill so Friday and bank holiday liberations that's covered in paper six so there's a suggestion for the committee to to follow that up with the sps and the scottish government I believe that particular provision might be in the forthcoming bail and release bill that this committee expects to see shortly so there's a suggestion at paragraph 17 in the paper about how you might follow that particular one up and in relation to access to work and the employability programme again at your suggestion Pauline that's referred to in paper six in paragraphs 18 19 and again there's a suggestion there for the committee's approval that you might want to follow that up with the with the scottish government so if the committee agrees all of those recommendations we'll follow up on all those points thanks thanks I agree with everything that you've said and that Pauline said is there any way we could also maybe include the the issue of you know interaction between the scottish prison service and the wise group or further through through care services because you know when we ask the question was there was there much cooperation that was quite a a sort of negative answer and you know I think sometimes offenders had to go and search for the information or or you know that kind of thing from the prison service so maybe just sort of to try and get more coordination there if we could if we could highlight that it might be quite good because they do provide a fantastic service I think that could perhaps be included in the letter to the SPS about the prescription issue identified by Pauline but yeah absolutely and Fulton you would yeah it was just I agree with others on yourself convener that I thought it was a very very useful visit last week and I want to put my thanks to those that gave us evidence and sometimes sharing their personal stories which obviously is very helpful for ourselves here but also that they talked about there being a national through care service in place and they're already providing that so they asked us to take that into account as we take forward the legislation which I thought was a very interesting point so I wanted to highlight that that's good thank you very much and collect thanks convener and just to say as well totally concur with everything everyone said today it's an absolutely excellent visit in terms of the recidivism rates that they've got was amazing to see that you know that that's fantastic that that's a measure of how how good they are and and just on that as well the plethora of talent and experience as well that the actual mentors had I was kind of blown away by that I was that was amazing and then again even some of the services that they've provided through the prison service like email a prisoner what a fantastic initiative as well so yeah absolutely totally taken by them and I've also emailed Charlie and Sean to see about during recess going to visit them for the full day and just connect to see what actual work they're doing so I'll keep in touch with them yet I think there was an open invitation to members to go out and shadow some of the work they do which I'll certainly also be taking up in respect of the email a prisoner I didn't appreciate that was a wise group initiative and in terms of the re-offending rates it's one question I perhaps didn't ask when I was there it was about how that's measured just exactly what that percentage relates to whether it's re-offending full stopper within a certain time period or but that's just a consideration sorry jimmy I just apologize for being unable to make the visit both apologies to the committee colleagues but also to the wise group but equally to make it open offer that I'd be very willing to go back with other members or visit on my own accord at some point at a suitable time I'm happy to arrange that through the committee clerks or directly with wise group themselves that's great and Audrey sorry just switching my mic on yeah I would just like to endorse colleagues on the committee convener in relation to the value that I certainly got from the the visit I have to be honest I didn't know much about the work of the wise group before the the visit and I learned a lot an awful lot about in particular their through care provision one thing that I would be quite interested in is perhaps learning a little bit more about the wider reach of the wise group across Scotland so for example up here in the northeast I'm quite interested in in what work they're doing or perhaps planning up in this area obviously we've got HMP champion near near my constituency so a wee bit of background in relation to that wider work I would find very helpful thank you that's great thank you very much I think we can certainly ask wise group for some some more information in that respect finally I'd like to ask members whether we agree with the recommendation in the paper at paragraph 22 which is page 4 of paper 6 yeah everyone agree great thank you very much and therefore that concludes the public part of today's meeting and we now move into private session