Does this work? All good? For the camera, so talk with your voice to the room. Okay. Hi, I'm Mananath Pataling. How much time do I actually have? You are 55 minutes. Wow, that's good. I want to get what you sound like. Excellent. So just to make this clear, if you have any questions, let's do that right away. Let's not wait until the end so that we can get a conversation happening here. I'm much more interested in leading the discussion into the direction that you wanted and much less into me actually covering all my slides because I know that I have too many slides anyway, and it's really about the discussion, not about the slides. Anyway, so yeah. Today I'm talking about re-inventing home directories. By the way, if any one of you has seen my talk about this very topic at All Systems Go or at DevCon, it's going to be the same thing. There's a huge queue there. If you have seen it already, it would be good to just leave and let me do it. You're not going to learn much new stuff. Anyway, apparently no one has seen it before. Okay. So yeah. What I'm going to talk about is Duller-Home. Right. As you know it, or TILA as you can even call it more briefly. Yeah. What is actually Duller-Home? Duller-Home is obviously directory as you know, right? But it's more than that. Like you always, for something to be a home directory, you also need a matching entry in Etsy PassWD, actually in Etsy Shadow and these kind of things. So it's currently, yeah, two things. Like it's a user account in Etsy PassWD and it's actually a home directory in Slash-Home. There are many problems that I've always seen with this idea. First of all, it needs a writable Etsy, right? Where writable Etsy, by that I mean that if you create a user, Etsy needs to be writable. I personally think we should go towards systems where Etsy is generally not writable, except if actually reconfiguration takes place. And I would claim that creating users and things like that changing users is not a configuration change, but it's more like a payload change, right? It's what you do with the system itself, like what you do on the top of the system, it's not reconfiguration how the system itself behaves. So yeah, I think that's kind of weird mix right now in Etsy between the actual state, which is if a user exists or not to me, and the configuration of the system, which is everything else that tends to be in Etsy. So another problem I always saw is that we have always have to on Unix propagate the UAD assignments between systems. If you have like an NFS LDAP setup, it's like madness to deal with that, right? Like because UAD range is relatively small, and hence we need to be very, very careful if the system can show up in some environment that the UAD is matched, because that's how we do access control and everything's messy. Yeah, in the world of like with LDAP and it was NIST before it and all these things, it's a major pain and with NFS to keep these UAD things in sync. I personally think for most cases, how people use computers these days, right? Like for example, how I use my laptop, this is kind of weird, right? Like because we do all this infrastructure for a propagating, but I think we shouldn't, right? Like I think it would be way better if the UAD would actually be an artifact of the local system, that only makes sense by binding some user record to the local system when we actually come up with UAD. That doesn't mean it has to be that way exclusively, it just means that I think we should go to that way where the UAD is more the local artifact and not something global that we are supposed to propagate that actually isn't global, because of course these fixed UAD assignments don't work outside of specific organizations. Another big problem that I see is that there's no encryption built into this, right? Like your home directory is generally not encrypted. You can't have encryption on the disk itself, like distributions tend to do full disk encryption or do the encryption of the home, but that's very distinct from the actual encryption of the home directory which doesn't generally exist. And that is weird because it has this, like if you do full description, I tend to use that on my laptop and most people probably here in the room also do the same thing. You have this weird thing that during bootup you actually query it for a password and that's the password that matters, right? Like that's the password that actually protects the data, but it's a system password and what the fuck's the system password? It's something like on Unix which was supposed to be a multi-user system, sharing passwords between multiple people is a very weird concept, right? So yeah, and then after you typed in that password where that actually mattered, you got to either authentication to GDM or where you'll get you whatever you wanna log into, where we ask for username and a password. And this password doesn't matter much, right? Like at that point the data is all unlocked, right? Like it's just about access control at that point anymore, and not about actually protecting the data. And this is really weird, right? Like first the important one that is like on a multi-user system makes not much philosophical like conceptual sense, and then the per user one which actually doesn't protect your data which just does access control and but it's the one that actually is inherently the multi-user stuff. So yeah, this kind of weird. Yeah, to be precise it's no user controlled encryption. Yeah, that's no, yeah exactly. I mean it's system controlled encryption, and it's not user controlled encryption. And that is like, I don't think we should do things this way, right? Like because yes, most of the time our laptops use single user systems, but I think still it should be, we should figure out how to encrypt the stuff, how to lock the stuff to the actual credentials you wanna lock them to. Right, like the system for example should be locked to the TPM. But your data should be locked to something that you control, your password, your UB key or something like that. Yeah, so I call that mismatching encryption. Right, you protect your data with it, but actually what you protect the data with is a system property, not a user property. There's also problem, no modern authentication mechanisms. By that I mean like we live in a world now where UB keys become a thing, but everything's bound still to one single password in Etsy PassWD. Now people have retrofitted UB keys into this, but it's always a little bit messy because it does not live in the actual user record. It's not part of Etsy PassWD, Etsy Shadow. It's part of something like a sidecar database, right? So the inherent user database design of Unix is around passwords and nothing else, right? So yeah, no modern authentication mechanisms. And we live in a world now where we probably want even more than UB keys and passwords.  But yeah, so we're kinda stuck in this world there which is very weird. It's also not extensible, right? And this is big one actually I think. Right now stuck past of UDs defines the same way as it was in 1985, right? It has these five fields. User name, user ID, group ID, real name, home directory and shell, okay, that's six. But it's beyond that, you don't get anything, right? You can't add a field there, it doesn't exist. People have of course always wanted to extend this. And they did, right? Like Etsy Shadow is like the first attempt to extend this, so they added like an encrypted password and they added some account meta information like how long is an account valid and things like that. But it's, yeah, many gain, I call them side card databases because they are managed independently of Etsy PassWD and carry additional information. These things get out of sync because, I mean, ad user for example doesn't care about, I don't know, the SSH key for example, because the SSH key like in your home directory, authorized keys file, that's a side card database, right? Like extending the user record in a way without actually having to get rid of the user record, right? So all these things then they get out of sync and they are messy and if you do resource limits, for example, you suddenly have a completely different configuration format, like PEMR limits.cont for these things. So which is inherently user information like how many resources you actually wanna give the user. But yeah, thank you side card databases here. Etsy Shadow is one. It counts damage like this GNOME thing that adds information about like a photo to the user and a couple of other things. That's like the perfect side card database because it actually takes the unique stuff and then the somewhat GNOME specific way tries to add all kinds of new and shit to it. There's Samba which maintains like a database for the CISID, the SID, which is like how Windows does user management. SSH has the SSH keys, PEMR limits does resource limits and things like that. And there's so much more than this. There's no resource management. Like the only resource management you get is PEMR limits. But what they said, like resource management are basically mean that yeah, if we actually have a multi-user system, right? You probably wanna assign a set of resources to specific users, right? Like because not all users are equal, the administrator probably should get more memory and see if he wants to or she wants to than a regular user. All right, so they're in a classic model. There's no resource management built in.  Because that resource limit is per process, right? So you can fork, you get a new set of resources fresh for free and then nobody will stop you from doing this. So how we actually wanna do resource management these days is we see groups, the kind of stuff that system manages. And we have nothing so far. So these are the problems I always saw. And it's kinda, yeah, if you start doing something like home dean, you figure out what do you actually wanna fix? This is the stuff we wanna fix. What we put the focus on is like, I mean, then you have to figure out what the focus actually, yeah, you wanna, who you actually want to use this stuff. The focus for home dean is human users, right? This is in contrast to system users like, I don't know, the user that you're a patchy demon runs under or things like that. So for home dean, I only care about human users, like me using that thing. In particular, laptop users, right? Like this is the world. On a laptop, you usually have one user, maybe you have two users, because your girlfriend uses two or boyfriend or whoever. But you're unlikely gonna have 1000 users on this one laptop, right? I mean, there's certainly environments which do that, but it's out of the scope for what I care about. So yeah, the amount of use you have on your laptop is below 10. It's kinda the focus. The goals that I wanna solve at the same way because I kinda like this is one of them, I'm not sure how much, how interesting this particular facet of this in real life, but I kinda found it a sexy idea, which is truly migratable home directories, right? All the way to the point of having a home on a stick. By home on a stick, I mean basically that you have a USB stick, and that this not only is where you store your home directory, but it is your home directory, meaning that you can plug it into this laptop today, log in and just works, and you can take it out and put it in another laptop tomorrow, log in there, and it all just works, right? So for me, migratable home directories means you have the actual data, but you also have the accounts information for that home record, all in one unified place, so they can just take it from this system into another system, right? So again, this USB stick thing, nice thing, and I'm pretty sure some security paranoid people will love this because it basically means you never leave actual payload data on the system while we are logged out because you just have it in your pocket and take it to the other device and only then you log in there. But in general, I'm pretty sure I personally wouldn't use this, I wanna store my data on my laptop because everything else is just, I don't know, I'm a lazy person, but it still is kind of useful that if I get a new laptop, I can just take this one file, which is my home directory and put it somewhere else and it's all in there. I don't have to reallocate the same UID and assign Etsy past WD in there and don't have to populate all this other side card databases so it all matches again with my old laptop.  Because we are bringing our home directory to some random machine, then how do we protect the home directory, we connect it to some malicious machine that someone has grouped account and can just open the content of our home directory? Even if it was encrypted, but at the time when we logged in, it was encrypted. So I'm not sure if I answered the question, but I'm supposed to repeat it, so the question was regarding how is this protected if you could copy it to some Roke machine that...  So the question is like, if you actually have your home directory on a pen drive and you move it from one machine to the other and you don't trust the other one, how does your data get prepared? It doesn't, right? The answer to this is, I mean, don't do that to untrust the system. So what's the point? I mean, what do you think? I mean, the point is really like, of course, you have to establish some level of trust between your home directory and the user, right? And we do this to some point. For example, when HomeD manages something, it signs the user records and makes sure that you have to have a signed record that actually has a key in the key ring that is on that specific system to do the other kind of protection. But inherently, the USB stick cannot, like it's a passive storage, right? Like it cannot enforce security policies on its own because it's not a computer. It's a storage device, right? So if the host has access to your credentials so that it can unlock your USB storage, right? If you were dumb enough to provide your password to that user, then it's freedom. Like the system can do whatever it wants, right? But the key of what I'm trying to design here really is that you have very clear life cycles that you basically say, when you're logged out, you're logged out. When you're logged in, you're logged in, right? And while you're logged in, you will get, or the system will get access to the device, but when you're logged out, it should not be possible to access your device, right? So that the moment where you decide to trust that machine, right, is the moment where you type in your password and only then the machine can access it. And then when you pull it out, it loses the ability to do this. But yes, do not plug this into untrusted machines. If you do, you're dumb, I'm sorry. So, yeah. The user and make sure that they are aware they cannot go just to the library and connect it to some random PC. Because so on, that's all my data, all my home directory. This talk is not about fixing the problem of untrusted computers, right? I think we should do this better. And there is like Chromebooks, for example, have a better model there, not a perfect model. But you can never have an entirely secure system because sure, we can lock things down in software and we should, but also, I don't know, I'm not capable of detecting a key law around my machine, like a physical one, right? So, I don't know, yeah. If you don't trust the machine, don't use it. But what I'm trying to get to here, right, is at least that it is very clearly defined like when data access is allowed and when it stops, right? So that, yeah, the only thing that the user has to do is like provide the password to the system and that actually truly unlocks access to it. So, yeah. Anyway, let's... 80% of your problems are solved with using ZFES already. So, why you never looked at it? For home directories in Chromebooks? I'm sorry. Snapshot is there, you can move to ARM, to Spark, to all of the architecture. Yeah, I don't think ZFES solves any of these problems. Like, first of all, like, again, home directories for me is something that is self-describing, right? Like, so you have the data store and you have the user recommended data. I don't think that ZFES does that. ZFES is a user manager that has, like, a user database in it. Is that your file system or your... Again, that's not what I'm saying. Anyway, let's have the discussion otherwise. I think this is, like, this is about user management. ZFES is not a user management dammit. It's a file system. And I'm not sure I have to have this discussion here about what the difference between a file system and user managers. So I'm sorry, but let's discuss it afterwards. Yeah, I mean, there's a general problem that configuration files are not always as stable as we wish them to be, but no, it's not in focus for this stuff. I mean, it's like, yeah, if apps break like this, it's nasty, but I think, you know, it's for the apps to fix. And it's... I don't think, I mean, the big thing that tends to break is usually the downgrade. Because app developers have an interest that stuff just continues to work as people update the stuff. But I think the problem becomes less of a problem as soon as we move to a model where software is always updated, because we have to move to that model for security reasons, right? And then this kind of is solved as a side effect, I think. Yeah, most of the problems with this won't have your stable release at work. Yeah, but it's... You always have to handle with that. It's kind of, you know, this is not a problem that is new to this model, right? It's a problem that you always had to deal with it, NFS, and these kind of things, right? But yes, you're expected to run the newest stuff in the world where we have security problems. And yeah. Anyway, let's go on with the slides for a moment. So yeah, the home directories shall be self-contained, right? Like the data shall not be distributed over the entire system. There shouldn't be an etsy-pass-w entry, etsy-shadow entry, and all this side card database. It should just be monopolized in one place. And that also means that the mere existence of the file home foobar.home synthesizes the user record, right? So you drop it in there, and that's a sufficient so that get and pass WD, like this Unix tool that allows you to, or Linux tool that allows you to animate all users, makes up, make sure that the user shows up, right? So, I mean, in a way, it's the most Unix-y thing you can do, everything's a file, right? Like it suddenly, the user becomes a file and in this self-contained. I kind of mentioned this already, but I want the UAD assignment to become a local artifact, right? Like so that at the moment where you log in, the UAD gets assigned and it's valid for this local system, but when you move the home directory to another system, then ideally you get the same UAD, but it actually doesn't really matter if it's taken there already, you get a different one. And we deal with this nicely. So, yeah, UADs become local artifacts. It doesn't mean they have to become that. If you actually want to have a fixed one, like to sell out, it's all supported, but at least it should be supported and it should be the default of behavior that people don't have to think about synchronizing UADs across the entire organization. This is kind of core of one of the SDS, that the unification between user password and encryption key. I kind of already indicated that earlier, that we have this current weird split where you have the password for the full disk encryption, which is actually the encryption key, and then you have the user password, which is distinct concept. I think this is wrong, should be the same thing. If I can decrypt a home directory, this is the same thing to me as authentication, and authentication would always be the ability to decrypt the home directory. So, that things actually are unified and people can actually understand this. Also, extensible user records, right? I talked so much about the SideCard database and how awful they are. Extensible user records basically mean that anyone can put anything in these user records. I don't have to care. We don't have to have a set of stone, set of fields, but the Samba people can, as I said, I don't know, the cavernous people can put their stuff in there and whoever wants to put more stuff can do this. It should be truly extensible and everybody can have their own fields, depending on whoever they wanna manage. Also, one important thing is like, we live in a world these days where full disk encryption is used, but also in a world where people don't turn off their computers anymore. I don't. I checked the uptime yesterday. It's like 50 days. I have not turned off my computer anymore. So, the way how full disk encryption works so far is always that, yeah, during British, apply the password and then it stays in memory all the 50 days that I've been using this computer. So, if you manage to steal my laptop and manage to access my memory, which is not as hard as you might think, you'll find my decryption keys in memory and can then decrypt all my data and that sucks. So, what should we do? We should make sure that when you suspend the machine, this stuff is erased from memory first, so that if somebody steals my laptop, I want it suspended, they still will not be able to access my laptop. It's really like as if you had a house and you would just put the key next to the door so that whoever wants to break in can just take the key and break in, right? So, fixing this, like Lux always had a concept of suspending access and just erasing the key so that this all works, but it was always extremely hard to implement in real life because if you do full disk encryption, the OS itself sits on the encrypted medium, right? So, if you want to re-request the password from the user when the system comes back from Resume, you need to ask the user for something, but it cannot be this OS itself because the OS itself sits on the encrypted medium, right? And that basically means that, yeah, if something's not paged in, you need to read from a hard disk, you cannot read from because you haven't supplied the password yet, but you are the one who is supposed to ask for the password so you deadlock and everything, shit. So, we need to come to a world where we can do this safely, meaning that the infrastructure that asks for the password needs to be separate from the stuff that we actually locked down where we flush out all the keys. Also, what is important to me is like, it's not all passwords anymore, right? Like in particular, I'm interested in PKCS 11 devices, like UB keys specifically, but also any kind of other device where we actually truly use them properly, right? Not for authentication, not just for authentication, but also for the encryption part, right? So that we use them as a smart card that they are and actually derives encryption keys for the Lux medium directly from the UB keys the correct way. So, yeah, it's kind of a key that, yeah, I don't know. I wanna be able to use UB keys at least and actually not just use them for, I don't know, it's not the indication that they're indicating to Google. I actually wanna use them to properly and securely protect my local system. So, a couple of complications with this. SSH logins is one of them. Like the problem is always like, if we lock this down properly so that unless you have provided your password there, it's impossible to access your data, you lose SSH logins to some point, right? Because SSH, you know how it works, right? Like it reads the authorized keys file from your home directory. So before you locked in, how is it supposed to do that if the home directory is encrypted and you can only decrypt it after you authenticate it? That thing is solvable and we solve it to some point because we're actually able to embed the authorized key stuff into the user record, which is available before you actually mount it. But then you still have the problem, somewhere, if you log in for the first time, the password needs to be supplied, right? Like, authentication via SSH keys, like how people use SSH means basically there's never a password actually exchanged, but we need that password to unlock the disk. In an ideal world, we could just fix it so that when you log in, first SSH does its own authentication and we would then simply ask the user, hey, please provide the actual password so I can decrypt the hard disk for you. Fortunately, the way SSH and Pam and these things work, we can't really do this. It's not a big problem. I know in the previous times I did this talk, people really, really hung themselves up on this issue. I don't think it's much of a big problem, right? First of all, it's about laptops. It's the stuff you log in with SSH out of. It's not the stuff you typically log in. If you do, you do it for emergency purposes and I can live with that to some point. Also, you can always do the same way, log into some other account that doesn't have these kind of protections and then locally provide the password to unlock it like there's a command for that and just log out and then log in really because as soon as it's unlocked once, the SSH works as it always worked because then the password is applied and then the home directory is mounted and everything's good. Just to make sure that we're on the contact, you mentioned that SSH keys are not part of the user records or anything, which means that they reside in plain text on the pendrive, right? No. No? Okay. So the question was regarding what about these SSH authorized keys? If they are part of the user record, do they reside unencrypted on the pendrive? No, they don't. If you actually, again, don't hang yourself up on the pendrive. I made that as an example, but I don't want you to think that home directory is on pendrive. You can do that, but let's forget about the pendrive thing. But no, we of course made sure that this doesn't happen. So the user record is actually stored three times per pendrive or loopback file. Once inside of the home directory, which is encrypted, once in an encrypted form in the lux header, which is entirely redundant. The only reason we do this is mostly because the kernel file system people made very clear that they are not interested in making sure that images, like file system images that you have that are rogue cannot exploit the kernel when you mount them, right?  So that basically means we always need to establish trust first, to some point at least, before we mount it, right? And the way we do this is by decrypting first that user record that is on the USB stick, verifying that it's properly signed, that it's a user record that's actually supposed to log in. And only then we go into mounting, so that the minimal level of authentication is established. But anyway, this user record is encrypted. Like the first one. And then there's the third one, which is actually copied onto the host the first time you log in, right? Because we still have to pin your user ID so that every time you come back you get the same user ID. That's important because the way Unix works if you have a file in some writeable directory somewhere, we cannot recycle the UAD right now. It's something we also wanna fix with sandboxing but it's a separate story independent of this one. But anyway, so yeah, you basically end up with three copies. A two on the stick, one on the system. And yeah, we carefully make sure that when you lose your USB stick on the street, somebody else picks it up, that the only information that is actually leaked to that user is your username, right? Like because we need that because if we stick it in then you have to still type something into your getty prompt or something. And then provide the password. And the password is when you provide it for the first time is actually the thing that unlocks the user record. Because again, as talked for earlier, we need to define clearly the point in time where this trust is established, where you provide the password to tell the system it's okay now, you may have access, I trust you. Disc space assignments. So with HomeD, like the way I like, HomeD is actually something that has five different back ends. The backend that I try to push people towards is the Lux backend where you basically either have your USB stick or you have a loopback file and slash home where everything is stored internally. But there are actually a couple of other back ends, like there's one for FSCrypt, which is like XD for online, like the encryption that is above the file system layer. There is also a couple of others, like plain directories, even if you don't care about encryption. But yeah, the one that I actually think that people should be using is the Lux one because it has the strongest security properties and allows you to do these things like raising the keys for memory when you suspend and more things. But it comes at an interesting behavior, which is disk space assignment. If we have a loopback file for every user and slash home, then it basically means, yeah, there's just like how you size that loopback file basically means how much data that user can store. Traditionally in Unix, we always said that, yeah, on my laptop if I have five users, all of them can fill up slash home as they want. They all fight for the viable disk space and the one who is lucky is lucky and the one who isn't lucky is not lucky, right? With disk space assignment with loopback files, you of course have to size the stuff a priori. We can resize online all the time. That's great, but that's exposed and homely. But you still have to, yeah, you basically get committed disk space assignments and if you think about it in a simple way, they cannot overlap, right? So that basically you lose the over commit functionality that how user management traditionally worked where you basically would say, yeah, even if you use you quota, you could say I have a one gigabyte disk but I give everybody two gigabytes of it, which made no sense, but you could do this kind of how we did this thing, right? So I don't think that's much of a problem because we have these nice behavior in Home D where you can do stuff like, you know, sparse files and discard. Like in Unix, we have this concept of sparse files where basically if you have a large file and it has zeros in it, you don't actually have to allocate space for these zeros, but you can just let the file system deal with it and tell it that this is empty space. You're not supposed to store it. Just when I read it, give me empty space, like zeros back. So, and we can use it all across the stack like that the loopback device does that and the file system device does that. And in Home D, we have this automatism that when you log in, we actually have allocate stuff for you so that actually this white space is removed. That basically means that while you're logged in, you get these guarantees that the one gigabyte you got assigned is actually what you get assigned. But when you log out, we tell basically the kernel to remove all the holes again, return it basically to the underlying file system so that somebody else will then logs in and can use them. The effect of this is, yeah, we give you guarantees that when you log in and you are assigned one gigabyte, you get the one gigabyte and nobody can take that away from you. If you're logged out, everything is shrunk to the actual space that you need. And other people can use it space. So, yes, just to answer because assignment becomes a little bit more complex, but it's actually, I think, very nicely manageable as long as you don't assume that you want multiple users to use your laptop at the same time. I'm not sure how that even would work because I only have one screen, one keyboard, but sure. So, yeah. There's also the problem of UAD assignments.  Like, because as I mentioned, I want that the UADs become artifact of the local system. And if they become artifact of the local system, we have to pick a UAD at the first login and assign it to that user that is not used on that specific system yet. But that is sucks because then all the files in the home directory will be owned by wherever this stuff was mounted earlier where it got a possibly different UAD. What do we deal with this? Ideally, we would just tell the kernel, mount this stuff and make all files owned by this UAD. Unfortunately, the kernel currently doesn't have that. Hopefully, eventually it does. So what do we do? We do recursive chone. Meaning that, like, when you log in and the U does matter, we just actually go to the file system and chone all the files. Sucks.  We're optimized for this kind of thing that dentry lookups are cheap. And so it's not as slow as you might think. Like, at least on my home directory with, I don't know, 500 gigabytes or something or more, it takes like two seconds if the UAD actually changes. Yeah, this comes up all the time. We can use the username space for that but actually I don't think we want to. Username space basically means that you have to have a sandbox around the user because he has to live in that or he has to live in it in that namespace.   People have done this before, particularly for file system namespace and I'm pretty sure we should go that way eventually. But it also means that, yeah, weird things happen because if you do these kind of mountain namespaces, then you see the system in a completely different way than you would traditionally do. With HomeD, I didn't want to go to that step yet, right? Like I think we should have sandboxing but also this is inherently supposed to be something that I want to use on my laptop, right? And if my user can't see the system anymore the way it is, then I'm going to have a very hard time with debugging that stuff. But you're absolutely right. Eventually we should have sandboxing and I don't know if I built a laptop like this and give that to my mother. She has no need to see all the processes owned by the correct users. So for her, we definitely want the sandboxing to work. Yeah, Lux Locking, I've already talked about this, like about the stuff that, yeah, I mean, so as mentioned, HomeD does this thing where when you suspend the system, all the crypto keys that actually used for Lux stuff is removed from memory. But then we have a problem that when the system comes back again, we have to provide the passwords again so that it can actually use your home directory. The way we address this right now is we don't. We have this requirement, basically, that after you come back from Resume, there's some kind of authentication taking place where we can read the password again from the user and user to unlock stuff. The way I think of this should work in the end of it, if you were, for example, if you use GNOME, that right now you get, when the system resumes again, you get this lock screen where you're supposed to re-authenticate, but this password always stays with the GNOME. And I think it's, yeah, and it runs, like this password prompt runs under the user ID of the user itself, which I think is problematic anyway, but that approach doesn't really work anymore because after all, if we come back from Resume, everything that is in the home directory and that accesses the home directory is gonna be suspended because we remove the key so that it can't actually read or write from that home directory. So what we do need to do there is that instead of doing the screen lock from the user's own session, we need to switch back to GDM or something to the display manager to some privileged component that asks for username and password. Then, when you provide the password, we can use it to unlock everything and then you can switch back. So this is a little bit of a complication, but to talk to the GNOME people, I think they're very much on board with making this work. As long as we don't have that, you can even just do switch to a GEDI, do a quick log in, log out again, and. What kind of design of the plain media where you're locked to? Sorry? Like plain media where you're locked to access to some data you want. For example, GDM, GNOME challenge, you can play your media, right? You're locked if you want to do that. Like media playing. Media, like your music playing. Well, I mean, it's like this stuff is supposed to be secure, right? Like so that you get this guarantee that when you're not sitting in front of the computer and have provided the password when you started using it, that nothing can access your home directory, right? Like the security guarantee that I want to give you because I think it's a good security guarantee. This does conflict if people want to do stuff with, for example, that I don't know, you get email notifications when you're not locked in and things like that, or that you can play music while you're not locked in. But yeah, that is fine even, right? Like in that case, don't suspend the machine.  Like, I mean, because then the music would stop playing too. Okay, so that's all you're supposed to do now. So. Yeah, I want to expand on that. Like I'm sending a big file to the server, waiting two hours. I'm going away because I need some coffee. I'm not going to sit. I'm going to log out. Well then, I'm losing access. And my download is not continuing? Yes.  So the question was regarding what happens if I do a long term, like a long download. And you traditionally, this person here solved it like logging actually out and making sure that the download continues in the background. What does happen if this is used? Yeah, I'll give you the guarantee when you're not in front of the computer, your data is not accessed by the system, right? And this basically means the conflicts with that stuff.  It basically allows you to say, yeah, leave this stuff around from this user when you're logged out. You can just turn this on, but that basically means you lose this nice property because that means the crypt keys need to stay in memory as long as your stuff logs out even if you're not sitting in front of the computer. So yes, you can do this. I don't think that it's nice semantics though, right? I'm pretty sure that at least on my laptop, I want to know that when I leave this stuff, that I know that nothing there can access my memory, that I don't know, everybody can steal my laptop and still not get access to my memory. This is a much nicer property that I want to deliver to people than, yeah, being able to finish downloads while I'm logged in. So yeah, I mean, this is conflicting stuff, right? I know like, I mean, we take away to some point cron jobs for you as well, right? Because cron jobs traditionally have this thing where they would run even when you're not logged in, right? In this model, it doesn't work, right? Like if you run stuff as unprivileged user while you're not logged in, somebody has to provide the password. And if you don't, because you had less cron job, then no way, you don't get to good do this, right? But this is entirely up to you, you know? If you subscribed into this model, like actually using Home D and getting the security ideas, you lose the property of being able to use your home directory with self-sindication. But then, if that is important to you, probably shouldn't use Home D or like, I mean, there's something we can probably do is that if you turn on this lingering thing that I mentioned, right? And that basically also means that we can basically set up the user context during boot instead of during login, right? So we could actually say, if you set up things like that and we need the password to actually work, that we ask you during boot. Like we always did full-fooled encryption for the password, so you log in once at that point. But this is not implemented. This is something that's relatively easy to do, but we don't do that right now. But I don't know, it's kind of outside of the model I want to go to, right? I want this lockdown secure thing. And that is like for me means that if I'm not at my laptop, nobody, nothing should get access to my data. How much time do you actually still have? 17 minutes. 17 minutes. So, actual implementation. I talked a lot about the stuff that I want to do with this. Now let's actually talk about how this translates to code. In SystemD, we added two concepts and all the last stuff was actually merged two days ago. One is JSON user records. JSON user records, like with all the stuff I talked about, locks and the actual home D stuff is kind of independent of this. Like the first thing I want to deliver is JSON user records. So basically is that, yeah, a struct past WD, you kind of have that in JSON now and it's fully extensible. And you can denote lots and lots of different properties. In SystemD, if you provide these JSON user records, we'll actually do resource management for you, couple of security things for you, couple of, like actually run other runtime parameters for you. But we can agree on some form of more modern way of talking about users. These JSON user records are not bound to home D. Like home D is one component that then makes use of this, but actually anyone can supply them, like anyone who's privileged on your system can provide additional JSON user records.  And we're mostly on the same page that, yeah, they're gonna supply from SSSD and this LDAP stuff. User records are the same format so that for the first time, they can, from the LDAP database, actually do proper user management, security management, that all the way propagates down to the system and SystemD enforces it. So, yeah, this is concept A, as mentioned, independent of home D. You don't have to buy into home D to maybe be able to make use of this. It's a superset of NSS records, so it's struck past WD and struck group and actually all the shadow ones and extensible. There's a var link interface, var link is some IPC system to query this and it's extremely dumb and simple. And the idea basically is that anyone, like any component that wants to provide a local user can just implement that var link interface once. And then clients can just ask them all at the same time and query those users. It's convertible forth and back to an NSS. Lossy, of course, because NSS records, like by NSS records, I mean, like struck past WD and struck group, go there, of course, don't have all the metadata, but SystemD will do all the conversion for you. So, it's up to you if you just wanna supply the classic NSS stuff, like most components currently do, then we'll generate JSON stuff on the fly, but the other way we'll also do it. Like, if you only supply the JSON stuff, then we'll generate NSS stuff for you if you want that. How does it actually look like? Here's an example, it's kinda complicated. Some things are pretty obvious, like username, like this user's called grovey, and I don't know, nice level means that when the user logs in, he gets a nice level of five. This member of is about groups, that this user's supposed to be a group, a member of the group wheel. Last change, usec, I guess I don't have to explain what that probably means. There's a concept of certain subsections, like the binding one is actually the one that maps a user record onto the local system, right? Like because a user record is something that I think should be independent of the local system, but some of it feels inherently, like for example, the user ID, like this one here, actually inherently have to have a local concept if we wanna do this thing, where we say that UIDs should be a local artifact. So, a binding is supposed to manage this, binding is basically yeah, this is the machine ID of the specific system, and then you store a couple of metadata specific on that specific system to it. I don't wanna go into too much detail about this specification upwards, if you wanna know all this, just to see that like privilege is basically where the hash password is like as a shadow. We put that in a separate section so that we can hide it from clients as they shall not have access. There's signature, which is like the cryptographic signature that I mentioned, how you can make sure that on a specific system only for example, users signed by the right-hand key can log in and answer systems not. Very good question. So, the question was regarding if user names have to be unique on specific systems? Yes, they do, because Unix works that way. But that basically, like so, I added a concept called a realm there, it's a little bit more of like a cover system realm, but it's also like domain, I didn't wanna define that any further. But the idea basically is that I can have user lennard at redhat.com and can distinguish it from a user lennard at, I don't know, Berlin, the EU, something like this, because they have a different suffix. But once you log in on that specific system, only one user lennard can exist, right? So it's a bit nasty that this is how Unix works and we can't really fix that. But I think it's probably in real life not that bad because on my laptop I'm probably not gonna have multiple lennards that are actually different. So that was the first thing, user records and JSON. Second thing is concept B. That's actually the homely part about it. So we have encrypted luxe home directors and loopback files, the stuff that I was talking about so long. I've mentioned that we have one file per user, like slash home foobar.home is a loopback file, a gigabyte in size, inside of that you have a lock stuff, you can actually mount that thing just with regular tools like you always did because it's just that, right? Like it's not the reinvention of stuff, it's just using stuff we already have and augmenting it slightly bit so that it's useful for user records. And yeah, if you mount it you find the JSON record, like the actual user record inside of identity there. But yeah, it's managed by the new service called system B home B. You can accept this and use it or if you don't have to, it's like entirely one provider of that user DB stuff but it's just one provider. If you don't wanna use it, don't use it, right? Like there can be others. So for example, if you're really, really bought into the LDAP concept that you have everything centralized and machine's kind of part of an organization if you so will, then you can soon hopefully use the user DB stuff but not use home D. Like home D is really about the use case where you have relatively migratable, independent of the laptops. I have a user directory here and I can migrate it to another one. It's all just works. Yeah, concept A, user DB records is independent of concept B in one way, right? Like you can use A without B but B implies A. Yeah, integration with the West, a couple of other components but I don't wanna go into much detail here unless you have no further questions because I think we have only 10 minutes left or something. So let's focus on questions. Sorry, what do you mean? I don't get it. How do you discourage us or even prohibits to just lock the screen but do not log out? No, it doesn't. No. How do you repeat the question? So the question was regarding if, as you understood, at home D prohibits locking the screen without actually logging out. But that's not true. No. Screen logging, screen logging. But screen logging means to me, that's the keys are left over there. Like you can, if you want to, turn this into something where you say basic screen log also means we flush out the keys. That basically means, yes, everything stops running. But we are not there yet. This is something we can think about but I'm not sure if you want this but if we do this, then it should be an option. But no, this does not imply this. This is something to think about that we might do later but no implication though. The idea is that you can migrate your home directly from your machine. What is the frequency of plan to do that? Is that a bare option? It just works. I personally work every day with two computers and I would like to carry a pen drive. Is that something that is just done in a minute that I can somehow do that? And if there are several versions of that thing there may be many unique backups. How do you do the versioning and what happens if I start using an overword and then I go to the new overword? Okay. So the question was regarding synchronization, right? Like if you have multiple users, you have the same user on multiple machines. Like how do we solve this? We don't. Right? So this is not a synchronization tool, right? Like I think having a synchronization tool would be extremely interesting. But it's, and I think this can actually be really nice because like, I mean, as soon as you have your home directory in one unified file, you can do stuff like actually distributing it to other systems in encrypted fashion without actually the distributing thing, actually knowing what it actually distributes there. You can do backups even like because you can do reflink, like because it's one file, you just do a CP with a reflink, you pay for nothing, you have a backup of that day and things like that. So I think the synchronization problem is a very interesting one and we should look into this eventually, but this one is not gonna solve this. And in particular, it's not gonna deal with deltas for you, right? Like with diffs between what you did on this laptop and what you did on this laptop because that is inherently something that needs to live above. Like if you actually wanna do proper diffs above the file system, above the encryption, because I mean doing diffs on encrypted stuff isn't really possible. So I think a very interesting problem, not gonna be solved by this, but I think it enables some things that we can make distributed stuff like this work. Like for example, that I don't know, if you are connected with a network that we just make sure that you're only locked in once everywhere and then whenever you log into something that your stuff migrate somewhere. I mean, you can even do stuff like for example, you can have your home directory on an iSCSI volume or NBD volume or something like this which is available to not your entire network, right?  It basically means that, yeah, if it's just there, it's gonna pop up as a user and then you look at any machine you like and you know that it's always shared because you always write to the same thing. We have no infrastructure for locking in this case, so don't actually do this, but it's certainly an idea. Like it opens a lot of doors where you can do stuff like that. But yeah, syncing is not solved right now and I think it's very, like the other problem with syncing is like, people disagree with what they actually wanna have synced. Some people want just the configuration, some people want the entire home directory. I have no nice answer to this. I know people have been looking into doing some syncing stuff. I don't know why this goes, but yeah, we have to figure that out. Groups with the same name, with your first design, you can define a user with some groups, but if you have common groups, but with different ones, what's happened? With different, what? With different? You can have the same groups, but on both systems could be different. So the question was regarding what happens if the groups that define differently on multiple systems, but you have one user that is accessing both of these systems. So first of all, you saw the JSON stuff, right? Like there's actually one section in there that's called per machine, where you can have static data that you configure and you can configure different, like from some of these settings, you can define per machine settings. So you could basically say, yeah, if on this laptop, the group foobar is something completely conceptually different than the same named group foobar on some other system, then you can basically say, yeah, on this one, I want to be a member of that, on that one, I don't, right? So first of all, that's one thing. Ultimately, the rule, though, is we allow access to anyone who has a user record that is signed by some key that is recognized by the local system, right? The entity that signs that really needs to take care of this problem, right? So I'm not going to solve this problem that if you have equally named stuff on different systems for you, that's the person who puts together the user record for you, who needs to deal with these problems and then maybe create per machine stuff or do something else so that this problem is fixed. Well, I mean, I'm not a standards organizer. So what's the state of the standard for the JSON user records? I'm not a standards organization. I mean, I kinda am, but also I'm not. Let me show you. Yeah, there's lots of interesting stuff in the slides, by the way. That's where the standard is. So if you go to this one, this is where the current JSON stuff is documented for the users, this is for the groups. This is for the vialing API to query it, and this is what we, it documents what we do if we use the lux home directory stuff, if you use that back end. Yeah, ours is extensible, right? And it's extensible in that fashion where you're not supposed to even talk to me if you want your own field, just take it, just namespace it properly, right? I'm not interested in being like this person in the middle who manages everybody's fields that's explicitly not what I want. Just pick a field you want, namespace it properly by just using a name that's unlikely collide with everybody else's and then add whatever you like. And then distribute it like Linux's, right? So, yeah. We talk about security. Is there a spread model on D because for me it resembles finger D. It resembles what? It resembles finger D. Finger D? Yeah. Okay. I think we should give access to the own directories. So I don't really understand the question, but if we did this spread model of this kind of stuff and because it resembles finger D, I don't understand why this would resemble... Maybe I would give access to other people to draw on that project to show which projects you have and which was followed with design. I mean, I know what finger is, but I don't see the relation to this. Finger is not about user records, and it's not about... I mean, again, this stuff is... If we put it in the home directory, that stuff is encrypted, right? We don't leak information. Unless you're logged in, nobody gets access to this. So it's actually only accessible to people who have access to the system. They can query the user database because that's how Unix always worked. But at that point, you also already have to have access to the local system. So I don't know if you want to implement something like finger D on top of this, you can use this stuff, but I don't see the relationship to finger D at all, I must say. Do you see the access to the home directory just like on DDesk? I don't see that, I'm sorry. How do I share a file? So the question was regarding how do I share files between two users? Well, you know, after both of them logged in, the users are not very distinct from traditional users, right? Like they'll both have a UID that's going to be sticky until the system goes eventually. Or they'll log out of each separate file? No, no, no, no. I do that when you do it on a different machine where the UID is actually different, right? So the question regarding like if you log out and log in again, what happens to the UID? Do we actually change it so that sharing files is difficult? So like first of all, you know, if you want to give other users access to your home directory, right? Knock yourself out. But also it's maybe not the best way to share files, right? So ultimately, like on a specific system, after you logged in once, we actually copy the user record onto the system so that it stays pinned and the UID assignment stays pinned. So that basically means that after you logged in once on a specific system, UID is guaranteed to be stable forever, right? We can only remove that limitation if we do the sandboxing stuff that we talked about earlier here, right? Because we need to make sure that you don't get to write anywhere else. But that basically means, yeah, if you want to use ACLs or to mod or tone or whatever else to give other people access to your files, same way as it always worked. Except if you then take that home directory and move it to a different machine, because if you do that, then you get the choning done. But that also means that we'll strip all the ACLs for you. Because, I mean, we have to because all the UID assignments and things like that don't make sense anymore.  But my answer is if you subscribe to that traditional model, knock yourself out, but then you don't get to get the truly migratable stuff. It's one or the other up to you. So are we going to have any, I would say? So the question, I mean, my time's over, but let's do this one last thing. The question is like, will we have a shared folder where you can actually share stuff between users? I mean, you can't do this. Homie doesn't do this for you. I don't think, like, you know, I'm pretty sure that in most cases when you want to share something with other people, we probably do it via, I don't know, telegram or email or something like this because inherently it means probably most of the people who want to share stuff are not going to use the same system. Like, at least, when I have shared a file with somebody else in the last two years, 20 years, they didn't have access to my local system, right? So I think the focus for sharing stuff should always be on doing a distributed, right? Meaning do it on the network and not on the local stuff. But again, write that infrastructure if you want this. It's totally doable to do already. Yeah. I think that's it. I don't have any further time. Thank you very much for your interest and for the questions. If you have any further questions, let's do that outside.


I don't know if anybody was waiting for this video from me, but I can tell you I sure was anticipating this package And I could not wait to create a video today. We are gonna go head-to-head I'm gonna show you the direct comparisons between the Charlotte Tilbury Hollywood flawless filter and the new elf halo glow Liquid filter. This is very obviously supposed to be a dupe for the Charlotte Tilbury elf was definitely coming For Charlotte Tilbury and normally do they do a good job. So I'm excited to test this out Let's get into it. So if you are not familiar with the Charlotte Tilbury Hollywood flawless filter I mean it is everywhere. It's been so popular for a few years now pretty much It's like a shimmery glowy liquid item that you can pretty much use for whatever you want to create a glow to the skin You can under paint with it. You can use it as a liquid highlight You can mix it in with foundations to make your makeup more glowy. It is phenomenal as a bridal makeup artist It's phenomenal for bridal makeup But pretty much if you want a glowy makeup look this has been the go-to. It is $44 and they're always sold out of a bunch of shades such a popular product and elf recently came out with their own version the halo glow liquid filter at only $14 which is expensive for elf. Don't get me wrong. That's expensive But it is $30 cheaper than the Charlotte Tilbury So I had to test it out I had to get my thoughts out for you guys and let you know if they are at the same or not The claims are literally the same. Okay, I mean elf did not try and hide Nothing with this one the major difference that I'm seeing other than the price point is the elf has less shades So in the elf it looks like there is only eight shades Whereas in the Charlotte Tilbury there are 12 shades But of course I'm sure Charlotte Tilbury had more time to expand the shade range as elf is just throwing this out There it is brand brand new also other than the price point What is different is the amount of product you get you get one full fluid ounce in the Charlotte Tilbury And you get 1.06 fluid ounces you get just a wee bit more product and again for $30 less. All right Here we go. Let's get into it So I currently own two shades of the Charlotte Tilbury Hollywood flawless filter. I have shade one and three So I did pick up shade one and three from the elf halo glow I don't know. I just wanted to see how those numbers would react and I did also buy number six Just in case I needed to deepen any of those smash a Charlotte Tilbury, but I've done side-by-side I don't need to do that, but I can do a swatch for you. Okay, so let's get into it This is going to be interesting. I'm telling you So in terms of packaging obviously the Charlotte Tilbury is a lot nicer a lot more luxurious But then is it worth $30 for the packaging? You know think about it like that and the elf is obviously a little bit longer But I mean the elf is pretty nice all things considered. Let's open them up So one thing with the bottles that's very different is the opening is in the Charlotte Tilbury is a lot smaller So you actually get a lot less product on the brush with the Charlotte Tilbury Which I prefer because that way you can't glob too much on that's something that I noticed with the elf already is that too Much product will glob on because of the larger opening both have dough for applicators You can see that the elf is larger the elf also has a bigger dip in the tip of the applicator So again, you get more product the concept pattern that I was noticing from playing with it earlier Is you just get so much more product on the applicator which could be a good or bad thing with the elf for me personally? I did find it a little bit annoying with the Charlotte Tilbury to have to keep going in and dipping But at the same time the elf was a bit much. So I would have liked something more in the middle Let's swatch the first shade. Okay, shall we so this is the Charlotte Tilbury shade one And I am going to put it on this side of my hand and let's get to the elf Shade one on this side of my hand now the elf in the bottle definitely looked darker for shade one And they still look darker as well I'm gonna use my finger and get the Charlotte Tilbury And then let's get the elf the elf definitely feels more creamy and thick a little bit more Moisturizing then I would say the Charlotte Tilbury does so that's Charlotte Tilbury versus elf We're gonna give that a couple seconds to dry. Let's swatch shade three Now I have shade one in the Charlotte Tilbury to highlight and work as a liquid highlighter And then I use shade three as all over for when I'm under painting. So this is Charlotte Tilbury shade three This is a little bit closer to my skin tone. This is elf shade three again much more product comes out The elf I would say is a bit more of a pinky undertone Whereas the Charlotte Tilbury shade three is more of a peachy undertone And they do feel a little bit different like I said the elf definitely has a thicker more Moisturizing feel to it whereas the Charlotte Tilbury feels a little bit more like a true liquid highlight Consistency one and three in both the Charlotte Tilbury and elf are gonna be the main comparisons today, but I did also pick up number seven I do know some people like to use this to contour with I'm probably not gonna try this today The main reason that I picked this up was just in case I needed to darken any of the shades I definitely want to try this as a liquid contour. You know what? Let me get the Charlotte Tilbury one I have the fair medium Hollywood contour one from Charlotte Tilbury I don't expect them to like be the same But I just wanted to see the color and here is Charlotte Tilbury fair medium And not that these are supposed to be doofs, but doesn't the color kind of look the same, right? Yeah, so the Charlotte Tilbury as you know blends out to be quite sheer so I can definitely tell these are two different products But I'll go side by side today with them. Why not? So I turned down the lights a good bit so you can really see the difference again. This is the Charlotte Tilbury side This is the outside and you can see for shade one the Charlotte Tilbury definitely is more bright Whereas shade one and elf I think could have been lighter and then shade three for Charlotte Tilbury Shade three for elf. You can see they're slightly different tones But I can tell you on the face and they're blended out You can't really tell the difference, but both of them look very very similar by swatch I would say the elf definitely looks thicker Let's get it on the face and you guys are truly going to be able to see I don't normally apply my Charlotte Tilbury flawless filter like this But for today's video for you to truly see the difference I am going to so I'm gonna start off with the number three flawless filter I'm gonna go one stripe here one stripe here one stripe here three four five five stripes of product and I'm not gonna use this as just my foundation today I'm going to use a concealer over top and I'll show you how I actually make it wearable when I do this I'm gonna use the Sigma multitasker brush and we're just gonna blend this out So I don't wear the flawless filter like this often I will sometimes and I'll put like a skin tint over top and it's really really pretty But I definitely feel like I wanted to for today's demo because I know a lot of people will wear this as foundation alone I'm not gonna use this as actual foundation alone today, but I wanted you to see it on a larger area So this is shade three of the flawless filter from Charlotte. I did just wipe off my brush Let's go into shade three of the elf and immediately just so much more product Thumbs off here is the outside. Let's blend her out So all in all the elf is definitely a little bit more creamy and thick So I kind of think in terms of spreading it along the face the elf feels a little better than the Charlotte Tilbury Now I'm not saying that that's a good or bad thing because I like how the Charlotte Tilbury is a little bit thinner So that way, you know, it works better almost as like a liquid highlight I think that's gonna help it set and last longer. We'll see but here's the difference. This is the elf and This is the Charlotte side. I think they look pretty darn Identical the only difference that I would say and this is me looking into a super magnified mirror and looking for something different Is that the elf looks a little bit creamier and more hydrating on this side? Whereas the Charlotte Tilbury is like the most little bit of less middle is more sheer and dry But that's because I'm looking at it really really hard. You can't tell there's two different products on my face So in terms of initial application their dupes period point blank. We'll see what lasts longer I genuinely believe elf had the Charlotte Tilbury in their factories and they were like going side by side until they Got as close of a formula as possible. I'm telling you. Okay. Now. Let's do the number one fair shade I probably will go in with a little bit more after I apply the rest of my face makeup But I just want to see how they compare first So this is shade one use a sponge shade one Charlotte Tilbury I know I'm giving you constant reminders, but we cannot confuse them beautiful now This is how I usually will use a shade as a liquid highlight and let's get into the elf trying not to apply too much of the elf and Then the Charlotte because the colors a little bit more different has a little bit more gleam to it I would say the Charlotte has a touch more of a metallic finish as opposed to the elf Which is a little bit more glowy so a little bit more metallic and a little bit more glowy And that's easier to tell because of the difference in color. So in terms of using this as a liquid highlight I think that the Charlotte Tilbury is going to do a better job Just because the finish is more metallic and it's a bit brighter for my skin tone. All right. That is pretty darn crazy Oh my goodness. Okay, and then finally not that we're comparing these but I am going to use my Charlotte Tilbury Hollywood contour wand just like this and use my sponge and blend it out And here's what makes the Charlotte Tilbury so special you can see it looks intimidating But it actually is very natural. I don't think the elf is gonna be it's just the way that it shears out That makes it look so special.  It doesn't actually look as crazy when you have a ring light ring lights do a lot Okay, let's go in with shade number seven of the elf I'm gonna use less because this obviously has more coverage So just a little bit more out here the elf one at least the shade that I'm using definitely has a little bit more Warm than the Charlotte Tilbury, but they both got their job done just as good I'm gonna fast forward through me doing the rest of my makeup. You'll see it. Keep it pretty light I use mostly concealer and you'll see what I'm doing But this is the way that I like to wear these when I'm using them mostly as foundation foundation All right, let's see how we go over powder So you saw I used a little bit of concealer and then I use the Fenty powder foundation in the center of my face When I wear these glowy products all over I do like to put a little bit of powder on top to kind of tone it down It will come through more during the day But that's the way I like to do it But now I want to go in with the lightest shade from both Charlotte Tilbury and elf and I want to see how they react now That we have a little bit of powder over our face. So we're starting off with Charlotte Tilbury shade number one fair I'm just gonna do two three dots and use my sponge And I'm gonna push it in and you can see what's beautiful about this product and this is why it's so popular You can literally do anything with it You can put it underneath makeup can literally put it on top of powder and nothing happens and it blends in seamlessly Let's give the elf same chance over here three dots one two Well, we'll do two because that was a little bit more product going in with the sponge Blending it in yeah, I'm thinking the Charlotte Tilbury works a little bit better as an actual liquid highlight There's just a little bit more gleam that it's giving me Elf is kind of just like being pushed in and that also is due to the shade Just being a wee bit darker, but it's giving me a little bit less metallic liquid highlight Then the Charlotte Tilbury is giving me but it's still very pretty don't get me wrong not crap talking at all That's just the difference that I'm noticing. Can you tell any difference comment down below? We're working through this together. Okay. I'm gonna do my eye makeup and lips And then I'll show you after everything has kind of settled how we're looking so over top of the makeup and everything My face has been sitting for at least a half hour I mean, I think everything looks identical. I literally Cannot tell a difference What do you think take a quick look So before we get into wear time, this is what I'm thinking about Charlotte Tilbury versus the elf I think if you are looking for a dupe for the Charlotte Tilbury flawless filter You literally have found it here elf did a great job now. What I noticed is the ingredients are different I'm not an ingredient bop, so I'm not gonna go over that if they don't have an identical ingredient list What I like the Charlotte Tilbury better for is more so on top of makeup because I feel like it has a little bit of a Dryer finish and more of a metallic finish. I think it looks better on top of makeup. It's more impactful But I actually think I like the consistency of the elf for Underpainting or for just getting that all over glow as the very first base because it is a little thicker It feels a little creamier. It feels a little bit more hydrating for my skin So in that case it almost looks a little bit more natural as well It is the slightest bit less Metallic so this is better in my opinion for under makeup Charlotte Tilbury is better for over makeup But they are pretty darn close I mean I suspect and I'm gonna see with where time that the Charlotte Tilbury might hang on a little bit better because it seemed a little bit drier and less creamy Of course, I will let you know and maybe if you have oily skin you might prefer the Charlotte Tilbury We'll see I'm gonna have to update you on that But yeah, I mean the elf is a dupe. I can't say otherwise I'm not gonna say I like one over the other elf did a really great job There's different reasons for when I would use what so I'm gonna be back in a few hours to let you know where I'm at and how my face is looking but so far looking for affordable alternative. This is great I'm really really excited about this. I also did before the day goes on one to show you how many makeup looks in front of the Window on my iPhone. This is the outside. This is a Charlotte side Identical can't tell a difference Both look great. So I wanted to close off this video by just giving you an update about how the product is wearing now Keep in mind. I have not had the most active day. I haven't gone outside today So it wasn't the best wear test Of course, as you know, I always do my speed review. So you will be updated But I think the Charlotte Tilbury definitely does wear a wee bit better It is not bad enough to where you need to get the Charlotte Tilbury over the elf I am noticing this is the elf side and a little bit more of the oils are starting to collect than the Charlotte Tilbury It's not super noticeable because like I said, I didn't do the most today But as I've been saying throughout the whole video, the elf seems to be a little bit creamier And so I think that is resulting in a little bit more of a shiny and oily appearance Compared to the Charlotte Tilbury, which did feel a little bit more dry So maybe if you have an oily complexion the Charlotte Tilbury might do you better, but both are still great elf Absolutely nailed this. This is a dead on do honestly If you don't want to spend $44 for the Charlotte Tilbury elf is the way to go For me, do I prefer one over the other? Like no, especially with that price difference I can't tell you that the Charlotte Tilbury is better or not But I'll tell you I do prefer the more moisturizing Qualities that the elf contains for under painting and I prefer the Charlotte Tilbury texture over top of foundation Because it's a wee bit more shiny, which is what I would want if I'm using a glowy product So anyways, I hope you guys enjoyed this review and found it helpful If you tried this product out, let me know down below Let me know which side looks better and I'll catch you guys in the next one. Bye guys. Have a good one


Apna, Apna, Sagras, and Apna. Hmm. Vigor wasps, flash flies, huh, they should be in ancient forest, moss wines, but they are a large monster. They're not a smart small monster. That could be why they show all. They should be in their endemic life if it is a large. There's a peritode, vigor wasps, more toads. They might be on the underground areas, right? Like 12? No, 12 is exposed. Let's see if I can, moss wine. Okay, so they're in area, they're over here. What is that? Is that underground? It is underground. Okay, so I have to go over here and go underground somewhere because this is ancient forest, but it's like an underground area. So I have to go to area 12, I think. Or a higher level? Okay, I have to go up then. Alright, not down, but up. No, just in case I need more of these, I'm gonna kill these two too. Get a big one first. There's one for sure, the camp near area 17. Oh, that's that, that thing we did the other day. So I have to somehow get to 12. Let's see that. I remember we did that, that thing to 17 the other day and we had to start from 12 and then do that freaking spiral up. Anybody see a piggy? There's actually one near area 11th on the ground level. Area 11. How come the filters aren't showing them? They are small animals. It's weird. The camp out in the east, jump out and walk around near the camp. Alright, let me see if I can, gotta figure out, how do you summon, how do you return to camp? I think you just go to map right and click on it. Alright, jump out. Walk around near the camp. Jump down. Please go back in there. He might be back in there. He wasn't over there and he's not here. Can't harvest. Oh, I can have his these bones. Trying to get mantle's chat. That's why I'm doing all these collections or deliveries. Oh, there he is. There he is. Been a sneaky bit me. Stay still. I'll move. That's good. That's a good little piggy. That's a good little freaking piggy. Jeez Louise. They sure do know how to pick them. That's a mossy bacon. Talk to me, talk to me, talk to me, lay day. Hey there, there, yeah. About you all. Oh. Oh. Hey, by Safari has returned. Let's see what they brought back. If I can find the door. Near the boat. Yeah. Yay, wait. What is all this? Bone, shells. Like an expedition. Sail, writer, voucher. Ooh, a voucher and some skills. Sure. I'll take all that. Okay, I guess I don't have room. I want to do this one. Wait. That's the best one. Let's take it back a notch. Moss wine jerky is the actual item. That's cool. If I remember right, most if not all the mantles are from quest. Yeah. I need eight. I don't have anything. The only one I have is the ghillie suit and I need more than that. I feel like I need the vitality or something. All right, any more quests. We'll have to talk to the lady up here. Maybe she's got an exclamation point for me. Fallen, what's up, man? Welcome. Nope. No dice chat. She didn't have anything for me. All right. I think that's all I can do. I've done all of my deliveries. I guess I just have to progress now. So we're going to do invader in the waste. Actually, let's see what new food we got. I should have got some new food, right? How do you go the next page? I'll just scroll. Unpredictable platter. Attack up. Comfort platter. Attack up. Feline medic. I don't know what these skills are. At some point, you think I would learn these.  Maybe you miss talking to an NPC. Oh, no, because I did be him. I think maybe I already have it. I have spent the last ever since I started playing this game. That's what I've been trying to get. I thought I didn't have it. I feel dumb now. Okay. At least you have it, right? Did you model your character after anyone? No, I didn't. I just want the pompadour and I wanted to make it blue for some reason. It's not modeled after anybody. I had the pompadour on my PS4 character too, but I had a male character on PS4. So I decided to go female on this one on PC. The pompadour. The blue pompadour. Okay. I feel better now. At least I have it. So one of the things I want to do now, let's not do this.  Heals confirm. So you I want potion. You I want max potion. You I want the the ration. You I want the well done steak arouni. Okay. Can I clear these other ones out? Anidot. So Anidot for the five or the five. Let's do the nullberry cheese first aid. All right. Ammo coatings. I would like to have piercing. I've did this. I've done this already. For some reason it did take. I don't know why. AC dotless cool. What up? No, no. Oh, okay. All right. I'll spread to your spread sticky and slice or sticky. Okay. Five. We will put the cluster and the liven poison and normal to actually I want poison on five. I use that more often and we'll put the cluster over here. There we are. So confirm it saved it two hours. David got it man. Got it. All right. F4 is the let's see. Do some stickers. Yeah. Let's do a greeting. Now let's do good work. Good work. Sorry and cry. What signal? Oh, that's a ping. Okay. And then I'll do a flare on six. I agree. Good work. Yeah, that's good. All right. So these should all be saved now, right? I hope. Yes. So I want to go back out there and everything's gone, man.  Okay. Now let's actually do some progression chat. Now we're actually starting our playthrough. You guys should have my my session ID and chat. It's also in the title. You want to join. This is we're killing a pookie pookie. So now I'm going to start using my cue bar just for my mantle. Basically, and I'm going to use these for everything else. I don't have anything I have three yet. It was like good work. Or I cry every time or I can put on my pierce animal, which is what I like to start with anyway. I got to eat. Oh, let me actually go in here and reload first. Wait, maybe the is the loadout have those two? Chat. Does your loadout include your radio settings? Oh, I need to set my loadout then.  All right. So I just saved my loadout. And now I got to redo it. Um, and get rid of all this stuff. There's only a few things like I actually want to keep some herbs. How you crap? 1010. No. Uh, what is this fire herbs only these latch berries? I guess you keep like 20 in this loadout. I don't know. Snow herbs. Now I get these out. No berries. Fill that up. Gunpowder don't need sort. Uh, how's ammo doing normal pierce? Let's fill that up. Let's fill this up. Spread ammo. Sticky. Fill that up. Cluster. Fill that up. I can't use cluster bombs to yet, but I'm going to keep it in here. Poison fill that up. Wyvern slicing. That's all the slicing I have. Okay. Um, let's put like 10 of these in here. And then we'll save our loadout again. And this should keep our custom bindings, right? Perish rooms, nitrous rooms. I don't think I'm using these yet. I was using these for coatings on bow. I remember that. Uh, I don't have any well done steak. I guess I have to cook it. Got the jerky. Burnt meat. Sorry. Boost natural healing and curious bleeding. Well, give me some of that. I'll do the rare steak too. I don't have any more, um, stuff. Life powder. I need to start using that more. Demon powder. Hard shell powder. Okay. I think that's good. Sort that. Uh, register this loadout. Okay, cool. I think I actually did it right. Can you do shift one, shift two instead of F1? I don't think so, man. Like, I think that might be like hard coded. I'm wasting time on my hunt, but I don't think I'll need that all the time anyway. Um, I think the function stuff is like, oh, hard coded. I don't see any way to change that. But the function keys. So you have to do that. Did I eat? I don't know if I eat. I'm gonna eat again. I did eat.  Welcome. Welcome. Let's kill all the things.  Gimmie, Gimmie, Cocoa Puff. Easy rations. Take some bottles. Okay. We got it. Shimmy shimmy Cocoa Puff. Those control options are there more EQ that are hidden? I don't know. Uh, Jubilis. Oh, you bought it? You bought it. Jubilis bought it. Yay. Um, what did you play again on, um, were you the one playing the music? Is this game the one where you play in the bagpipes? Those are the bagpipes, right? We play the game together. You play in bagpipes. Oh, that was so good. That was so good, man. Um, dude, I tried the hammer. I like the hammer, but I haven't done a lot with it. But the bow gun, I'm just, the light bow gun might be better. But this heavy bow gun, I'm really enjoying this. I think it's better than the bow, actually, honestly. This pookie pookie? I don't think this is a pookie pookie. If you really want to challenge, go for that, that, uh, either the charge blade or the, um, that's better off. Uh, charge blade or an insect glaive. I hear those have high, high skill caps. Oh, these dudes. What's up? Crap. I can't get anything from them yet. Give me that. Give me your poop. Yes! Dung pods, chat. They scare monsters away. So I think it was DBRN. He just flew away. I think it was DBRN, so the monsters kept ruining it. If you use dung pods on them, it scares them away. All right, at least we got them. He's being tracked. Yeah, if you use dung pods on monsters that invade you, they, they run away, I think. You guys can correct me if I'm wrong and chat. Oh, speaking of which, this is a case where we might want to scare somebody away, chat. See how that worked? Now, wasn't that cute how I just shot poop in his eye and he ran away? This is a good thing, chat. Oh, he's right here. Let's kill him. Did I block that poison? Definitely didn't block that poison, chat. Oh, wait, don't do this. Do this. How do I put on this mantle? There we go. Oh, is it no berries? Or is it antidote? I'm so clueless. There we go, antidote. He tried to get me a can, chat. All right, we got this. Gotta get used to this stuff. I can't hit him in the head. There we go. Beautiful. Not poison. It was slicing now. I think I prefer using the scroll wheel for ammo, specific ammo. He always gets me reloading, chat. Still got the poison. Six, right? Five.