WEBVTT 00:00.000 --> 00:09.920 We continue and it's a little bit of a set talk because there is a thing that's on the 00:09.920 --> 00:15.960 bring beauty to the web which is both CSS and I think that we will have here starting 00:15.960 --> 00:19.760 now that everything is beautiful that but I am very pleased to be on the web. 00:19.760 --> 00:20.760 Thanks for the introduction. 00:20.760 --> 00:26.160 So my name is Daniel and today, yes, we're here to talk about CSS, Cascading Style Sheets 00:26.160 --> 00:29.200 or as we like to call them Cascading Spy Sheets. 00:29.200 --> 00:30.680 So why are we here? 00:30.680 --> 00:35.120 Basically, I'm going to show you how you can profile recipients of an email climb. 00:35.120 --> 00:40.080 So you send over an email to someone and then you magically figure out which operating system 00:40.080 --> 00:43.880 they're using which software have installed at least some of those features to then just 00:43.880 --> 00:46.480 better think and print your clients. 00:46.480 --> 00:49.880 What you can also do and we will see that in the second half of the talk is you can send 00:49.880 --> 00:54.480 over an email with an encrypted content, so we're talking about enter and encryption 00:54.480 --> 01:01.080 years, especially PGP and then magically you can decrypt the content and all that with CSS. 01:01.080 --> 01:05.560 So the rough agenda is of course first off we are introducing CSS and especially some 01:05.560 --> 01:10.120 neat features that we use in our research and afterwards we're talking about client 01:10.120 --> 01:11.120 thing operating. 01:11.120 --> 01:15.400 So what can you learn about a client by just sending them some CSS and some let's call 01:15.400 --> 01:22.680 it a special email and in the end we will leak and exploit actual text from an email 01:22.680 --> 01:24.040 client. 01:24.040 --> 01:25.040 So who are we? 01:25.040 --> 01:29.000 I'm saying we because originally this talk was supposed to be given by three people, 01:29.000 --> 01:34.920 Leon Trumbert, Misha Elchvadz and me, unfortunately two of us couldn't make it, so I'm 01:34.920 --> 01:37.000 here alone. 01:37.000 --> 01:41.680 Our group typically works a lot on microarchitectural attacks and side channel attacks 01:41.680 --> 01:45.280 and what we're seeing today is a little bit towards our side channel attacks and 01:45.280 --> 01:48.040 evap and in email clients. 01:48.040 --> 01:54.000 So first off, well, CSS, I am pretty sure most of you have seen CSS and some 01:54.000 --> 02:00.320 form or the other already, what probably especially in this room most of you already also 02:00.320 --> 02:04.480 know is you can even have CSS and HTML in emails nowadays. 02:04.480 --> 02:08.960 So if you for example want to send an email with some orange text you can just use that 02:08.960 --> 02:14.620 use a little bit of CSS to color your text and well that just works because email clients 02:14.620 --> 02:16.880 render CSS as well. 02:16.880 --> 02:21.040 So CSS nowadays can do a little bit more than that. 02:21.040 --> 02:25.600 So modern CSS of course still has some basic features like properties for example to encode 02:25.600 --> 02:30.120 the colors but it goes also a little bit deeper nowadays because you have functions. 02:30.120 --> 02:33.720 You can even have something like the call function which gives you automatic expressions 02:33.720 --> 02:38.560 that you can abuse and we'll see that later on or you can just do things like fetching 02:38.560 --> 02:42.960 and remote image and loading for example a different background or something. 02:42.960 --> 02:47.800 And we of course also have selectors so we can apply these slides to certain elements 02:47.800 --> 02:51.600 on your website and we nowadays also have ad queries. 02:51.600 --> 02:58.540 So conditionals inside CSS so for example this query is only what a style inside that 02:58.540 --> 03:05.480 at rule is only applied when your screen is at least 700px in it's with and these conditionals 03:05.480 --> 03:10.400 are quite neat because you can have something like this depending on the screen size 03:10.400 --> 03:15.800 of your device you fetch two different images from the server because they evaluated 03:15.800 --> 03:21.480 in the order of specificality so which means the second query is a little bit more specific 03:21.480 --> 03:27.000 than the first one so it takes precedence which means if your screen is at least 700px 03:27.000 --> 03:32.280 in it's with for example a normal desktop then you will fetch the later image and if 03:32.280 --> 03:35.880 it's smaller than that for example because you're in a smartphone you will fetch the first 03:35.880 --> 03:41.000 image which means that if you're the one operating that server where those images are 03:41.000 --> 03:45.880 posted you will directly learn something about your user's devices you will learn its 03:45.880 --> 03:52.280 screen size and that's the idea that we're following here but we're not talking only about 03:52.280 --> 03:58.040 things that typically use CSS so like browsers but we're talking about email clients right 03:58.040 --> 04:06.280 so email clients will become in all forms and colors and whatnot so with web mails we have 04:06.280 --> 04:10.440 desktop clients and we of course also have more web clients and the neat thing about that 04:10.440 --> 04:15.400 is especially when we're talking about CSS that under the hood a lot of these features are 04:15.400 --> 04:22.200 very similar why is that because well for web mail we of course for styling can use the rendering 04:22.200 --> 04:27.240 engine of the web browser for desktop clients we sometimes do the very same thing and just 04:27.240 --> 04:32.680 use the rendering engine of a modern browser and for mobile clients we typically use the rendering 04:32.680 --> 04:40.440 engines of the standard browser of the device so essentially make clients also just restricted 04:40.440 --> 04:47.240 I have to say that but essentially just browsers and well there's even one exception to that rule 04:47.240 --> 04:51.240 because typically you would now say okay but you cannot execute JavaScript or anything fancy 04:51.240 --> 04:58.760 like that in a made client which is technically true almost everywhere well during our research 04:58.760 --> 05:04.840 we figured out that for some of those clients this case some of the email you sometimes find 05:04.840 --> 05:10.760 weird corner cases so you could load an iFrame there and inside that iFrame you could actually 05:10.760 --> 05:16.760 execute JavaScript which means you could execute JavaScript code to fingerprint users which 05:16.760 --> 05:24.440 well was also considered a backup by some of the email and is by now fixed so it does no longer 05:24.520 --> 05:31.320 look like this instead you cannot do that anymore but still just with styles so CSS you can still 05:31.320 --> 05:38.360 categorize make lines in basically two groups we call them lenient lines and restrictive clients 05:38.360 --> 05:44.360 whereas lenient lines allow a little bit more than the others and basically in our research we did 05:45.400 --> 05:51.640 we sent out a lot of automated the generated emails to the look at the responses from all kinds 05:51.640 --> 05:57.000 of different made clients and ended up with this list of clients and everything that is on the left 05:57.000 --> 06:04.840 hand side also one very cool UCS feature called container queries and container queries well you see 06:04.840 --> 06:10.440 one here so based on the width of a container you either apply your style or you don't which is 06:10.440 --> 06:15.320 I have to say that very given very similar to media queries but with one important difference 06:15.320 --> 06:21.240 you do not check for the screen width but for the relative size of some container so something 06:21.720 --> 06:26.920 where the element you're talking about is inside so the parent of that element which means you 06:26.920 --> 06:34.600 can actually reason about the size of something on your website so well how is that now relevant 06:34.600 --> 06:43.240 in any case um do you think is you can do with measurements with that okay I have to maybe say 06:43.240 --> 06:49.560 why that is important now um well take a look at different clients and different clients may look 06:49.640 --> 06:55.960 the same but if you can have very precise measurements of the width we will also preserve the 06:55.960 --> 07:01.720 depending on the fonts that are applied by a certain client you will also see elements of a different 07:01.720 --> 07:07.480 width if you can now measure this width you can of course learn which font was applied to that 07:08.120 --> 07:13.160 which means if you have a client that has font x installed and another client doesn't have that 07:13.160 --> 07:18.920 font you can actually distinguish that and well if you want to build code extracting that information 07:19.000 --> 07:24.600 it could look like this so here we have two elements two diff elements and the inner is just 07:24.600 --> 07:31.560 called yes the outer is called target and the target one basically um x is our container so 07:31.560 --> 07:37.960 we can define that this container now or suddenly uses the font chilled sense and chilled sense is 07:37.960 --> 07:42.760 a very nice font for that because it's typically just installed once you have the office suit 07:42.760 --> 07:48.440 installed so without Microsoft Office you probably don't have that font on your machine and then we 07:48.520 --> 07:56.040 give it a width that is relative to that font itself because one cap is a special unit always 07:56.040 --> 08:03.720 defined by the font in place and now if we have a conditional based on that based on the size of 08:03.720 --> 08:10.280 that container which has the size of its font we can actually query for example url on our server 08:10.280 --> 08:16.440 and we only fetch the resource if the client has office installed so that actually leaks that 08:16.520 --> 08:23.560 information to us which font you have installed and we can do some ferritrix like this for example 08:24.200 --> 08:29.400 we build an automated tool to just execute code expressions to figure out whether there are differences 08:29.400 --> 08:33.560 in there and it turns out if you have the following code expression and you execute that on an 08:33.560 --> 08:41.640 inter CPU you end up with 13 obviously if you execute the same thing on an arm CPU you end up with 08:41.640 --> 08:46.920 almost 13 and of course you can now do the same thing you can build a conditional differentiating 08:46.920 --> 08:53.160 those two values so whether something is bigger than 13 or not and yes and that's very continues 08:53.160 --> 08:58.040 for quite a while and our paper we have more details on different features that you can abuse and 08:58.040 --> 09:02.920 turn into conditionals and leak them and again and then you learn a lot of information about 09:02.920 --> 09:08.520 your clients when they're opening an email but well how is emailing or printing even useful 09:08.600 --> 09:13.160 and of course it's always in life they're different motivations striving people so we can for 09:13.160 --> 09:17.720 example assume everyone only has good things in mind then we can build something like leak detection for 09:17.720 --> 09:22.600 example suppose you have a very important email and your company you send that to all your employees 09:23.160 --> 09:28.200 and you now want to see whether that what you want reading that email was actually from your company 09:28.200 --> 09:33.240 or not you could build a fingerprint only matching people from your company and well if it matches 09:33.240 --> 09:37.960 someone from your company you know everything is fine if someone else tries to open that email 09:38.040 --> 09:44.040 well then that fingerprint of someone who's not belonging to a email is also sent to you 09:44.600 --> 09:49.480 and you can see that difference at fingerprint so you learn someone in your company leak that 09:49.480 --> 09:55.800 information through some way else at least forwarded that email of course um speaking about 09:55.800 --> 10:00.680 fingerprinting naturally we can also speak about tracking here you can also use that to enhance 10:00.680 --> 10:06.520 things like the tracking pixels well now you can also add to your tracking pixel the operating system 10:06.600 --> 10:13.880 of your user for example which is a need depending on your perspective and your take on privacy 10:13.880 --> 10:21.240 so what can we do about this well of course all these things rig or so far we've seen required 10:21.240 --> 10:27.640 resources to be loaded from some remote server so we can stop these remote resources from being 10:27.640 --> 10:33.480 accessed and typically also may clients nowadays do that so they if you open an email for 10:33.480 --> 10:38.840 example you typically see that that they prompt you for your that you actually have to accept 10:38.840 --> 10:44.120 loading remote content and the reason are exactly things like that so you do not want to fetch remote 10:44.120 --> 10:51.400 content of course what you can also do and for example proton mail dust is you can as a mail 10:51.400 --> 10:57.080 server you can just unconditionally fetch all the resources so depending no matter which 10:57.080 --> 11:01.960 your unconditionally also flight you just fetch everything proxy everything and then only handle 11:01.960 --> 11:07.640 those requests from your proxy server which means on this server side as a attacker you only see 11:07.640 --> 11:13.320 all the requests being requested at once and then you don't learn anything but even if you add 11:13.320 --> 11:18.120 these things you can still do a little bit of nasty stuff for example you can build very sophisticated 11:18.120 --> 11:23.800 speed fishing miles now you can craft an email that for one thing a print looks like a fishing email 11:23.800 --> 11:28.440 but for someone else for example your IT department opening that mail it looks completely benign 11:29.000 --> 11:33.720 and if you don't look behind you certain of what actually goes on in the source kind of that 11:33.720 --> 11:40.360 mail you don't see that difference at all so maybe accept those two mitigations we also want to 11:40.360 --> 11:48.840 think about restricting some of these HTML and CSS features in our mail clients well and that's 11:48.840 --> 11:55.080 quite some tricks that you can use to think up print mail clients but the question here is of course 11:55.560 --> 12:00.760 that's everything and here can we do more than thing-apprenting and of course I 12:01.320 --> 12:06.120 spoil out myself in the beginning of this talk we can do a little bit more and how did we can 12:06.120 --> 12:13.240 end up with this is funny thing so during our research we tried something like this we used a style 12:13.240 --> 12:19.240 but instead of directly loading that style we imported it from some remote URL and if you think 12:19.240 --> 12:23.960 about that from a mail client perspective it's a little bit harder to sanitize some of these things 12:24.040 --> 12:28.840 correctly because you cannot just go over it sanitize all these things because some are just 12:28.840 --> 12:34.360 lazily fetched from some remote URL and it turns out if we did that and you so go make a client 12:34.360 --> 12:40.200 and for example just apply the purple background our make lines suddenly look like that 12:41.240 --> 12:47.480 which means we could apply this style not only to our email but to the entire the client and 12:48.440 --> 12:55.160 we then ask ourselves like okay that's weird our client now looks well not as good as before anymore 12:55.560 --> 13:02.600 but we also apply this style now to a lot of text also text that we are supposedly not be able to read 13:03.240 --> 13:11.320 which brings us to leaking actual text with CSS so how can we do that and the idea that we follow here 13:11.400 --> 13:17.240 are basically three separated steps first off we measure the dimension or we generate text based 13:17.240 --> 13:23.640 dimensions then we measure those dimensions and then we repeat everything so the first property that 13:23.640 --> 13:30.840 we abuse are fonts and one certain feature of fonts, ligatures so ligatures um for those of you that 13:30.840 --> 13:35.160 are not aware of those features you see in the right hand side of this slide basically you can 13:35.160 --> 13:40.760 fuse certain characters together to look better in your font and how that works is interesting 13:40.840 --> 13:47.000 because you can just build something similar to regaxes so you pattern matching in your font 13:47.000 --> 13:51.800 where you can say if f is followed by an i then you apply the following ligature 13:53.160 --> 14:00.040 which means that if we for example for one second assume we know two characters already let's see 14:00.040 --> 14:07.480 let's say we know s and e of our text we can build 26 different ligatures for the next character we 14:07.560 --> 14:15.480 can build a ligature matching s e a s e b and s e c and because we're designing a font now we 14:15.480 --> 14:21.320 can of course also choose the width of these ligatures and we can just make them unique and well 14:21.320 --> 14:25.960 if we apply this depending on which character is actually third one we see a different 14:25.960 --> 14:32.040 ligature in that font hence a different width again which brings us back to where we were before 14:32.120 --> 14:39.000 measuring width and we see already how we can do so we can just now build a cascade of 14:39.000 --> 14:45.800 lot of container queries depending on which width we apply it we can just delete that character 14:45.800 --> 14:54.520 to our remote server just again accessing summary mode URL well the only stuff that remains 14:54.520 --> 14:59.960 now is we can leak one character how can we leak multiple and for that um well 15:00.440 --> 15:05.480 Leon had a very smart idea here we can just use cs as animations so yeah 15:10.280 --> 15:16.680 thank you so the idea is well we can just apply different animations and for each animation we 15:16.680 --> 15:24.440 leak the next character and what we do here looks like the following first off we do the same trick 15:24.440 --> 15:29.560 that we already seen to mention the very first character of our font or of our text that is 15:29.560 --> 15:36.520 inside an email then we sent that leak to our server now on your server side we create a new 15:36.520 --> 15:43.400 font that already contains that first character and we sent that new font or we hosted new font 15:43.400 --> 15:50.120 on our server and if now the animation triggers while we are or after we process that new font on 15:50.200 --> 15:56.040 our server and hosted a new font and now the client reloads everything well then we can apply 15:56.040 --> 16:02.200 that new font because luckily animations lazy load fonts so we can build the font for the second 16:02.200 --> 16:08.520 character based on the observations from the previous ones and all that it takes years that our 16:08.520 --> 16:15.560 server is fast enough before the animation actually um steps to the next step so the our performance 16:15.640 --> 16:20.040 here is just a round trip time that we have to beat a little bit of computing the next font 16:20.680 --> 16:26.360 and if we do so for example for the so-called client we could leak everything in that box so we could 16:26.360 --> 16:33.000 actually read subjects of other males so we just sent you an email you open that email and we could 16:33.000 --> 16:40.360 immediately send cd text that you see on your screen there and we can just leak these subjects of 16:40.440 --> 16:47.640 other emails that was also assigned to cve and a spinoff fixed but that brings me to email and to 16:47.640 --> 16:53.160 an encryption because now that we've seen how we can actually leak text we can do also 16:53.160 --> 17:00.200 the same thing for end to end encrypted emails so for end to end encrypted emails basically our 17:00.200 --> 17:05.800 fat monolistic following use an email to some recipient and every server along that chain is 17:05.800 --> 17:12.040 untrusted you don't trust anyone basically and what these servers can now do is what they can't 17:12.040 --> 17:17.640 read your email because it's encrypted but I can for example append something to that email but 17:17.640 --> 17:23.560 why should that matter anyway so if we talk about emails and now a little bit about the 17:23.560 --> 17:28.680 form of an action email we can have so-called multi-part mixed males which means we have two parts 17:29.240 --> 17:33.640 these two parts can for example one-half HTML and if your client doesn't support it doesn't show 17:33.640 --> 17:40.200 HTML you can just have a fallback so some plain text here but what we can also of course do 17:40.200 --> 17:47.800 is an attacker we can attach some of our evil HTML containing some CSS now the big question is 17:48.680 --> 17:57.000 is that CSS applied to whatever comes afterwards and of course sometimes it is always a wooden 17:57.080 --> 18:03.880 show this here and the very cool thing here is from an attacker's perspective that your clients 18:03.880 --> 18:10.520 decrypt the encrypted emails for you so if they show everything to you they of course have to 18:10.520 --> 18:19.880 decrypt that so when is our style applied is well a question of in which order everything is 18:19.880 --> 18:25.880 rendered here and the thing is what happens for some of those clients is you actually decrypt 18:25.880 --> 18:30.600 that mail in your client and then you apply this style so what you end up with is the attacker 18:30.600 --> 18:37.560 controlled CSS applied to initially encrypted emails and of course then we're just back to 18:37.560 --> 18:44.040 leaking an encrypted message because the encrypted message is just now decrypted automatically by 18:44.040 --> 18:51.320 your may client and well then we do the same trick again and we can leak the content and 18:51.960 --> 18:59.400 that works on what worked on Mozilla Thunderbird it got assigned in CVE and is by now fixed it 18:59.400 --> 19:07.000 also worked on KDE mail and it almost worked on Apple mail the Apple mail the thing there is that 19:07.000 --> 19:12.360 they don't naturally support PGP so you need to have an additional app in this case GPG so 19:12.360 --> 19:17.880 that you could do the same trick but because that's an external app again that you cannot extract 19:17.880 --> 19:25.720 something from there we could not leak that content so well that basically shows you a lot of things 19:25.720 --> 19:33.400 can go wrong and well we wanted to end this talk with well because some of your are trusting your 19:33.400 --> 19:37.080 may client some of your building your own may clients you wanted to just end this talk with 19:37.080 --> 19:43.480 the lessons that we think are the most important after these two research papers and that is 19:43.480 --> 19:50.200 if you design your own may clients if you're making choice of a certain may client maybe think 19:50.200 --> 19:56.360 about the following two things what can go wrong is message isolation we've seen that you should 19:56.360 --> 20:04.120 probably isolate every message on its own and by message there by I mean not only email threats 20:04.120 --> 20:10.760 so replies can also be malicious for example every message on its own and also be careful to not 20:10.840 --> 20:17.720 apply everything to or if you render something do not apply trusted and untrusted stuff in the same 20:17.720 --> 20:23.720 domain also sanitization can easily go wrong we've seen that in the so-called may client for 20:23.720 --> 20:29.560 example but it tried to sanitize your HTML mail but then once you have recursive imports for that 20:29.560 --> 20:37.080 and import at import rule for example things get very hard to to correctly sanitize again so 20:37.240 --> 20:45.560 you can do it but it gets hard so be careful there our recommendation instead is for if you really 20:45.560 --> 20:51.240 want to protect the privacy and and the security of enter anecdote emails is you may think about 20:51.240 --> 20:59.400 isolating per entire message and maybe because just our feeling is academic researchers it's 20:59.400 --> 21:05.320 maybe a less error prone think about framing instead of sanitization on namespacing so do not 21:05.480 --> 21:10.520 add some random prefix to your elements but for example just use an i frame or something and 21:10.520 --> 21:18.840 sandbox that so that brings me to the end of this talk um well i hope i convinced you that CSS 21:18.840 --> 21:24.600 and style sheets are general are very powerful and they're more than well just some style that 21:24.600 --> 21:29.400 is applied to your mail but in the hands of an attacker malicious person they can actually be used to 21:29.480 --> 21:37.080 infiltrate your privacy or security so well that's an actual threat by now and especially in 21:37.080 --> 21:42.760 the context of enter-end encrypted emails message isolation gets important because we've initially 21:42.760 --> 21:49.880 also seen that a couple years ago with e-fail and we think that what e-fail showed us back then was 21:49.880 --> 21:55.800 the tip of the iceberg but the bigger picture that we now also try to evaluate is that you should 21:55.880 --> 22:01.000 just isolate trusted and untrusted content from each other and be careful also with applying 22:01.000 --> 22:06.360 styles from one thing to another there thank you very much i'm happy to take your questions 22:13.640 --> 22:18.520 you mentioned a message isolation but I suppose that more parts isolation like parts of a 22:19.240 --> 22:26.280 yes the question is about message isolation and whether we want to isolate the parts in 22:26.280 --> 22:33.000 the message yes definitely so we we're also really when in this angle slides thinking about what 22:33.000 --> 22:39.480 term we use there but yes the most specific and correct term in this situation is parts 22:39.480 --> 22:43.880 of a message everything of this mutual or everything ideally should be mutually untrusted to each 22:44.840 --> 22:48.120 HTML should just be yeah exactly 22:57.240 --> 23:03.320 what about replies because if I reply to a message that message is usually if I find a bit 23:03.320 --> 23:09.560 for example it quotes the HTML literally including the CSS puts so that's what you're 23:09.880 --> 23:15.960 formatting have you looked into this because there's a discussion right now if I'm 23:15.960 --> 23:23.000 never like do we sanitize replies to such a CSS so the questions about replies and whether 23:23.000 --> 23:29.400 CSS from replies it's also it's also applied to the origin of my and we thought about this 23:30.440 --> 23:36.120 we never looked really into that and especially not into multiple my clients and how they handle that 23:37.000 --> 23:42.840 yeah that's still I can imagine 23:56.280 --> 24:01.480 it depends a little bit on like this work was also done over 50 course of one and a half years 24:01.480 --> 24:07.960 because this talk was about two research papers most male client vendors were quite responsive 24:07.960 --> 24:16.360 to us and like it depends a bit a little bit on your flat model right because the privacy 24:16.360 --> 24:23.720 issues were not given out CVE directly something more CVE like the text exploitation later on 24:23.800 --> 24:29.800 what's given CVE's by fun or by what's given a CVE by Thunderbird for KDE male it's still 24:31.160 --> 24:38.440 an ongoing fix discussion so maybe I can update you really near future about that 24:40.120 --> 24:45.800 but I would say generally the working together with vendors was quite fun and 24:46.760 --> 24:54.120 helpful right so I have a red meal and then mocks my meal server I use the iFrame to isolate 24:54.120 --> 25:00.680 the HTML and you see the security policy to defend loading and so on is that something else I should be 25:02.120 --> 25:11.000 using the isolate so the iFrame's and whatever it's been got a question is what besides iFrame 25:11.000 --> 25:18.120 and simplex and what else is there you should be aware of we can't think or i personally can't 25:18.120 --> 25:24.040 think of anything more right now so out of experience what we saw is well I remember a client 25:24.040 --> 25:30.200 kind of a sound thing a lot of them were already secure against those things i would just 25:31.000 --> 25:35.480 I think if you have in mind an in-fret model that these things kind of lie and that for example 25:35.560 --> 25:41.080 untrusted even styles can be an issue i think then you're good to go i think the you made 25:41.080 --> 25:48.280 issue that was also raising those concerns was that people purely our hypothesis that the 25:48.280 --> 25:53.000 people three styles just as styles like what could go wrong if someone colors your text right 25:53.560 --> 25:58.120 and we now show like you can do a little bit more than just color your text you can 25:58.120 --> 26:02.520 extortate information there so if you have that in mind i think you're hopefully good to go 26:04.120 --> 26:09.080 i'm Kai i'm working on a lot but thank you very much for your research and to work with 26:09.080 --> 26:16.840 it was very very helpful and i would like to say that is that we should also turn this into a 26:16.840 --> 26:23.160 powerful action and for you to feedback because there is this balance that on the one-high 26:24.040 --> 26:30.360 uses this because there is one group of users who wishes to see as much as security as 26:30.360 --> 26:35.400 profitable and are willing to accept downgraded you are and then on the other hand 26:36.520 --> 26:43.000 users who expect that everything looks great and crazy right so i would like to see more community 26:43.000 --> 26:49.800 feedback what users impact what are you willing to accept by default so so i would like to encourage 26:49.880 --> 26:58.520 people to approach this on the project with your expectations yeah and yeah just just i want to 26:58.520 --> 27:04.360 mention that yeah these three things are all disabled in some level by default because by default 27:04.360 --> 27:10.360 remote content is not enabled but thank you anyway because many people do enable remote content 27:10.360 --> 27:15.720 those important yeah i should add to that i'm exactly what you said like for some of those 27:15.720 --> 27:20.280 exploit especially some of those main clients are very privacy aware and disabled quite some of 27:20.280 --> 27:25.160 those features by default it depends on a little bit on the users configuration of what it takes 27:25.160 --> 27:31.480 you can mode or what it takes you can't mode so yes i can't agree more like this discussion 27:31.480 --> 27:36.440 of usability versus security is ongoing and all of our applications are right and especially 27:36.520 --> 27:44.440 make lines and now for things like well beauty versus well threat model like all the these things 27:44.440 --> 27:53.080 together that it becomes even more relevant thank you my question was that similar to this 27:54.600 --> 28:03.560 it of your experiences over the years you basically are this to notebook correct but you 28:03.560 --> 28:12.040 will feel that all these issues like short amount of images yeah so um 28:12.040 --> 28:18.200 question is whether when we filter all remote images over that's fine um basically like i also have 28:18.200 --> 28:23.640 this one slide where you have spearfishing some stuff still works and what you can for example also 28:23.640 --> 28:29.960 do and i didn't or i couldn't go into detail there in this talk um is if you can change the 28:30.040 --> 28:34.040 content of your mail for an internship that may have for example you can still smooth signatures 28:34.040 --> 28:38.280 because you can have a valid signed message but if you can change and modify the content of the 28:38.280 --> 28:43.720 mail or make it look different then you can still do something in that direction but of course 28:43.720 --> 28:48.040 the more severe variants of that they can be blocked if you just block our remote content 28:49.480 --> 28:57.000 the other hand is that user experience suffers by that that's of course well maybe maybe a very 28:57.000 --> 29:04.000 hard trade or for that all right thank you very much again