Google Paid Me to Talk About a Security Issue!


Written by:

I’m really excited about this video, because
Google wanted to sponsor a video talking about a security vulnerability that somebody found
in one of their products Think about this: They want to pay money,
so that I very publicly share “Google had a security issue”. That might sound CRAZY for most other companies,
but we know Google has always had a great Vulnerability Rewards Program. They have always been very open and inviting
when it comes to bug bounty. But still, this kind of exposure to a much
wider audience is an experiment. So yeah, they basically said to me: “look. We connect you to some bug bounty hunter,
so they can tell you about a vulnerability they found. And just make a LiveOverflow video like you
always do.” I couldn’t imagine anything more perfect
than this. They didn’t give me any talking points,
didn’t say what I can’t say, just “make a LiveOverflow video”… Alright then! So because of regulations it says “advertisement”
up there, but believe me, all they did was: asking a couple of researchers if anybody
would be up for making a video with me, and so here is Wouter. Also known as wtm. He is from the Netherlands and is a full-time
bug bounty hunter, and spends a LOT of time researching and finding bugs in Google products “Basically Eduardo got in touch with me
and asked me to demonstrate a bug to you. I think it should give you an idea of what
kind of bugs google is looking for. And it also should provide some background
information on how you can start finding bugs in google products. Anyway, this is my approach. Other people might be doing it differently. But I will show you a bug and you can do with
it what you want.”So the bug Wouter found was in the Google
Cloud Console, specifically in the Cloud Shell. As you can see, this looks like a regular
IDE. A text editor to write programs. But there is more to it, because when you
look here at the bottom, you can see a shell. Here is how Google describes this app : “Your Google Curated Admin Machine
Google Cloud Shell provides you with command-line access to your cloud resources directly from
your browser. You can easily manage your projects and resources
without having to install […] tools on your system. With Cloud Shell, the […] gcloud command-line
tool and other utilities you need are always available, up to date and fully authenticated
when you need them.” While this sounds like a sales pitch for potential
Google Cloud customers, it’s equally a sales pitch for bug bounty hunters: “Everything you can do on the cloud platform,
you can do from this box.” In other words: “TARGET ME! I’M VERY CRITICAL! FIND BUGS HERE AND IT GIVES YOU LOTS OF MONEY!” “I’m opening my project by default. But this can be any project. I can create a new project and open it the
same way. And the only thing this thing does at the
top, it configures the gcloud client. So it’s already configured, and you can
start working immediately. Let me show you. So now you see my session is configured for
the dev-shell project. And when I issue this command, you will see
some instances I created for this demo. So you can imagine if you can compromise or
gain access to another user’s cloud shell, it would mean you can get access to all resources.” Awesome. I guess everybody understood the purpose of
this web application: You can manage all your cloud services, and because of that, it’s
very critical – so it’s a great target to hunt for bugs. But it’s also a complex system, which means
you first have to get familiar with it. And one particular feature seemed intriguing: “If you look at the documentation, you can
see Google is stimulating people to open GitHub repositories into your cloud shell. Because it’s a place meant for development. So you are likely to pull in some code from
github to do some development. You can see they provide you with an API.
you can create buttons in your github repo like this with markdown. So what this basically does is you open a
cloudshell URL. And then you pass in the github parameter. And when you open this URL it will download
code from github. It will do a git clone and will appear on
this side. I will show you with a repository I prepared
for this. If you click on this button, you will see
it switches over to cloud shell and it will ask me if I want to clone this stuff into
my shell. There is nothing special about it. It’s just a git clone. So I assume it’s safe and I clone this. Okay, here you can see it’s starting to
clone. And that’s basically the readme from my
github repository. Why is this feature so intriguing? He looks at it this way: So my initial thought was: You can easily
download content into your home folder on the cloudshell. That’s what it’s meant for. You download github content into the cloudshell. But is this content really safe?” Okay, that’s a great research question,
right? That’s a good direction to look for. But how do you figure out if downloaded content
can do anything bad? You have to be sure, that no other processes
are interfering with the content we’ve just downloaded. So I started looking into the inner workings
of cloudshell to see if any other processes are looking at the contents I run in my home
directory. To see if there are vulnerabilities there. That makes sense! You download files into your home directory,
but it’s just a git clone. So in order for something bad to happen you
either find a bug in git clone itself, or something else has to access the files and
do something bad. And “something else” is, of course, another
process. So he had to figure out if some process reacts
to the files being downloaded. Which means he has to dig into the inner workings. Now let me show you a bit about the shell
itself. If you look at the processes running inside,
you can see there is not much going on. Because what I was expecting at first when
I saw this. I was expecting to see some IDE related processes. As you can see there are no IDE related processes
here. So this must be a containerized application. So I wanted to start finding bugs in the IDE.
it’s called theia btw, the IDE. It’s open source you can download it to
play with it. There is a lot of stuff going on, but you
can only see part of it. You only see the ssh connections coming in.
and you see some scripts used for monitoring, to make sure google knows you are alive. But other than that, there is not much going
on inside your shell itself. Looking for bugs in this open source project
theia makes sense. You could for example look for XSS issues
triggered by files that you open in it. Or maybe the markdown rendering has bugs. But he was wondering why you can’t see the
theia IDE when looking at the processes. This means the shell and the IDE run in different
parts. One thing that I noticed is that there are
two docker sockets available. This one is the default docker socket. As we check this socket out, we can see there
are no containers running. So this infact is a docker inside docker. My container, my cloudshell is running inside
a docker container, but within docker container we also have a docker socket. But one that is really interesting I thought
is this one. That is, as you can see in the pathname, it’s
a docker socket running on the host. And that in itself is not a security vulnerability
but it allows you to escape from this containerized environment. Since we are allowed to connect to the host
itself. Wait what? Escaping the container is not a vulnerability? Let’s checkout the docker documentation. So docker works essentially by having a docker
deamon process, which waits for commands by a docker client. So the docker command line tool simply interacts
with the daemon via a socket, and you can say “please start or stop this container”. Throughout the docker documentation you can
find several traces about what this means. By default, a unix domain socket is created
at /var/run/docker.sock, requiring either root permission, or docker group membership. So there is a “file” that is a so called
UNIX socket, and it basically can be used to talk to the daemon. And only root can talk to it, or any user
in the docker group. And on another article there is a big warning
about this: Warning! The docker group grants privileges equivalent
to the root user. For details on how this impacts security in
your system, see Docker Daemon Attack Surface. And on there they write: Only trusted users should be allowed to control
your Docker daemon. Docker […] uses a UNIX socket. You can then use traditional UNIX permission
checks to limit access to the control socket. And the reason why it’s so critical is because
containers are not really isolated like a VM from the system. If you can create arbitrary containers, you
can just mount anything into a container. So you just gain access to the whole host
system. That’s why access to this socket is like
giving somebody access to root. So yeah? Why is this not a vulnerability here? And I think this is a great lesson: Context
matters. Yes you can escape that one container, but
is the host system here really critical? Some people would consider this a vulnerability,
but I know people at Google do not consider this a vulnerability. Because it all depends on what you do on the
host. If the host doesn’t contain sensitive information,
it’s not a problem to look around on the host and see what’s underneath. And funnily enough, some time later, somebody
else shared this finding on Twitter: One-liner Docker escape from Google Cloud
Platform’s Cloud Shell to the host OS. And they added:
Reported to Google and it was determined to not be a security risk. So always keep that in mind. Every target might have a different threat
model and sometimes it can be very weird. I made a video once about a few interesting
edge-cases for vulnerabilities, I link it up here, in case you are interested in seeing
some discussion about it. But anyway. Let’s see how the escape works and what
insight it gives us. You can see here that he executes docker,
but specify a different socket. Not the default socket of the docker daemon
inside the container, but the socket from the underlying host. The host’s docker daemon. Secondly we start that container and give
it some extra priviledges. So we mount the proc filesystem, sys and the
root folder of the host. And then we attach host-based networking. You can see at the moment we don’t have
the host based networks available. These are internal IPs reserved for container
networking. And then we give it all privileges and all
capabilities.then we start it and execute a shell. And As you can see, it allows us to look a
bit deeper into the internals of what google is actually doing. Over here you saw we have mounted the rootfs
inside the liveoverflow container. And I will just change the root into that. So we are now still inside the container,
but this container has a lot of privileges. And when we now list the containers inside,
you suddenly see what’s underneath the surface. And I will not go into detail of all of these
containers, but it should provide other reasearchers a way to get started on cloudshell, or perhaps
other google products. Because I’ve noticed other google services
have similar architecture. Now the two most important containers. Are this one. This is our shell. And this is theia, it’s the editor we see
at the top. Awesome! Now we really get some deep insight into the
environment. And that’s also where he spent a lot of
time on. For example, he tried to visualize all the
different containers and how they interact with each other. Yeah, it takes a bit of time. And of course this is not the entire picture,
because this is just what I am seeing. I’m obviously not sure if this [is correct]. There are mistakes in my overview. But it works for me. According to this overview I managed to find
a few bugs. And if I find new information I add it here. In case you wonder how exactly Wouter figured
that out. It basically just comes down to having a good
broad understanding how software is built and how you can debug stuff. Let’s do an example investigation. Here he used his new privileged container
to get into the theia container, the IDE. And as you can see it’s a stripped down
container. So you will have to install some additional
software to start debugging. So he installs procps and strace. Procps package contains tools like “ps”,
so you can list processes and strace can be used to trace systemcalls. I have used it many times before on this channel,
it’s a great dynamic debugging tool. BUT he has a problem, because this container
runs without the capabilities to use strace. Or to be more precise, the container is not
allowed to use the syscalls that strace would want to use for tracing. But from understanding the architecture of
the system, he found out how to modify this container. It’s actually orchestrated by kubernetes,
and so he knows how kubernetes works and simply modifies the kubernetes config yaml file,
and adds those security capablities to this container. Cloudshell will reboot, and that’s because
kubelet picks up the changes and wants to make sure the pod keeps running in the state
as described in the yaml file. I was actually surprised that with these container
changes the website just refreshes and reconnects to the IDE again. Hahaha, It surprised me too. But it took a few tries. Because I think I’ve lost connection like
50 times and then you have to wait and reboot the machine. But now it works. And I have posted this on github so everyone
can download it and give it a try if they like. When telling you the story of how he did this
research, it sounds always so easy and straight forward. But I hope this comment by him gives you some
insight how frustrating, slow and tedious this kind of research actually is. We are just summarizing into a few minutes
probably hundreds of hours of work. So now we can enter the theia container again
and start debugging some of it’s processes. Okay now you see the main process of theia. And we will be able to attach to it. We will write the output to a temporary file. But then suddenly everything broke again. It rebooted. Sorry. I don’t know what happened. I just wanted to keep that in, because I need
to keep reminding you, this is tedious frustrating work. Annoying stuff like this always happens. In a video it can look smooth, but real-life
is not. Anway… let’s fast forward to tracing the
theia main process. This is setup. And now I will connect strace to the ssh daemon
on the shell environment. Okay now let’s say we create a new folder
java code as you can see some processes are running. I will close strace. And see what happened. This is the theia container. The IDE container.And it connects to the actual
cloud shell to start basically this jar. On this end we see the same systemcalls. Here we see the jar files firing up the language
server. But what I’m interested in is the behaviour
of the language server itself. Okay. Now you saw one example how he is able to
trace and see what is happening. And he found out that when creating a java
project, it starts this java language server by using ssh to execute this jar on the other
machine. There are language servers for any programming
language. Such a program is used by something like this
editor, to provide information for auto completion, it can check for syntax errors or can also
help with syntax highlighting. And so here he discovers an attack surface
with the language servers: This file we just created. But this can be any file I just cloned from
Github. So it’s important that anything from GitHub
is secure. And that the language server is treating it
the way it should. If he can find an issue in the language server
that is started when you open a certain file, maybe that could be an issue. And that’s what he found. So this is just a regular repository. We have a java file we are trying to compile. Well we are not trying to compile it, but
it’s happening anyway. Let’s see what happens. Okay it’s in dutch and asks us if we want
to clone this repository. Yes we want. You see the new directory popping up. My repository is being cloned. Yeah the language server is being fired up. Inside this workspace I created a build.gradle
file. And inside this gradle file. Oh yeah, it just happened. Our code was executed. And this is the vulnerability. Wouter found out, that for whatever reason
the java language server just automatically starts compiling any java project. And gradle build files allow to specify shell
scripts to execute during compilation. So without the user hitting build or executing
a file, it just did it in the background. And as we mentioned in the beginning of the
video, anything running in this shell can access all your other cloud stuff. So this is kinda bad. But here you can also see a very specific
security boundary that google has defined. It should be safe to clone any repository. Of course if you clone an evil script and
actively execute it yourself, that’s your own fault. But a user does not expect a git clone to
lead to arbitrary code execution. And Google didn’t know about this behaviour
either, this was not intended and that’s why this is a vulnerability. And I know you are curious, he got 5000$ for
this. That was really interesting. I personally learned a lot from this. At the end of our conversation I had the chance
to ask him a few questions and got some great responses I want to share with you. Do you report every small odd thing you see,
because it could be a vulnerability? No I try not to send in everything. I believe my acceptance ratio is around 97%. Because you don’t want to waste google’s
time. These are highly skilled and expensive engineers,
so you should think about everything twice before you send it in. You don’t want to put them into the position
where they need to decide on the quality of the bug. And most of the case you just need to send
in quality and wait what happens. How much time do you think is spent on researching
new targets and how something works, versus actually looking for bugs? 70% of my time just doing reconnaissance and
finding something that’s interesting enough to give a close look at. But when you find something as for example
like this target, then things start to shift and suddenly you can spend 100% of your time
looking into these bugs. But overall I would say 70% of my time is
just spent on finding the next thing to look at. Did you have any notable dead-ends when looking
into this target? That’s hard to say. I wouldn’t have one specific dead-end in
mind. But of course when you are doing bug hunting
you have dead-ends everyday. Because you have an idea, you try it out and
9/10 times they don’t work how you think they were working. So I would say dead-ends are just daily business
to me. I hope you enjoyed this deepdive into the
bug hunting process. Maybe it even inspired you to head out now
and research an application and possibly even find some bugs. I have linked the resources about this bug
in the description, checkout the google vulnerability rewards program And please let me know: isn’t
this kind of sponsored video the best match that could ever happen for this type of video? What do you think about it? So thanks Google for supporting this.

100 Replies to “Google Paid Me to Talk About a Security Issue!”

  1. Jacek Plays ❶ says:

    Click bait

  2. Jon-Anthoney de Boer says:

    Excellent find, love the concept of this video too.

  3. vision light says:

    nice for making this video, i know that finding bug can be frustrating unless you happen to find it accidentally, but this video showed me how even more frustrating it is. thanks!

  4. mist3rx anonymous says:

    No, they always show it in movies, hacking is really easy and fast forward 🙂

  5. Marc Droz says:

    you deserve it! all the sacrifice you've made for learning and working on your skills, keep up the good work!

  6. Marat Aziat says:

    coooolllll more!!!!

  7. Say my name? Harambe says:

    This is awkward. Your normal video is not showing your face let alone half of your body. But nice video though.

  8. Michael Scott says:

    That’s awesome! Congrats man 😁

  9. Zak Cheb says:

    Screw docker, podman is the solution!

  10. Elie Obeid says:

    5k is peanuts for a career, he wouldn't find bugs at companies who's willing to pay everyday, therefore it's nothing.

  11. twat2019 says:

    nOOOooO i DINDT WANT TO SEE YOUR FACE, its still hot tho

  12. junosoft says:

    5000 usd seems low

  13. Miller-STGT says:

    I enjoyed every second of this. Hope they will hit you up more often about bugs like this.

  14. TooTall Dan says:

    Cool content and research. Thanks for sharing. BTW, I hope you get paid twice because there were 2 commercials in this video also.

  15. Lukas Dzunko says:

    Docker escape bug (?) is still there …

  16. Morph_k says:

    Bug hunter hired by google, congratulations

  17. Tv8g says:

    Wie zijn er hier ook verders Nederlanders? xD

  18. Jake Hillion says:

    Loved it. Thank you.

  19. Rippster says:

    pls do these kind of videos again.

  20. James Adi says:

    I don't have any clue about what's going on, but I'll return here !!

  21. Kaapalkeens says:

    So in a nutshell:
    JavaScript is executed without user's permission

  22. Glory To Arstotzka says:

    I am really happy for live overflow geting asked by google themselves to make a regular video with a bug they had. feelsgoodman

  23. LuXxenatorX says:

    5000 LOL

  24. Axel says:

    Funny they paid you for this. There is a way bigger problem in Google.. If you look up a company for opening hours or a adress 8/10 this is a mimic from a malicious hacker group that replaced the legit company with a spoofed one that steals your information.. If you do this on your phone everything on there is now stolen and copied to use against you. Same for your PC… But Google doesn't care..

  25. Sev M says:

    19:19 why does the hair suddenly disappear?

  26. XDRosenheim says:

    Google: Sponsors a YouTube video.
    YouTube, a Google company: Wait, can we demonetize this?

  27. roygalaasen says:

    Maybe you get a job offer from Google soon!

  28. E. Camilo says:

    It is amazing that you show the effort this guy had to find this bug. I know people who think success is a one time try-get thing based on someone's "talents". This line of thought can lead to many disappoints in life.

    Your channel is amazing 🙂

  29. Ka Bi says:

    Imagine that the background script were running the chrome and open the specify link

    Rick roll lol

  30. Ali Houadef says:

    I activated the bell icon.

  31. WelteamOfficial says:

    One of your best video imo. Thank you

  32. Pcpie says:

    best video

  33. MannyLama says:

    Love this video! Great work.

  34. Code Chapter says:


  35. Tyler H. says:

    Docker demon

  36. Nullbyte says:

    Awesome, as always! 😀

  37. sharpblade444 says:

    Although I enjoyed this video I really hope it won't stop the cool session of videos you've started with cheat engine + ghidra on game hacking

  38. Rishav says:

    google wrecked my laptop. fuck you google.

  39. Lamawalrus says:

    Yeah good sponsorship sir

  40. User says:

    ¿Does someone knows if there is a reason for VS Code UI looking like Theia IDE?

  41. allah mainster says:

    Great now i can host Minecraft servers on Google cloud shell

  42. autist69420 #0069 says:

    G E K O L O N I S E E R D

  43. Njul says:

    19:07 you removed his beautiful haircut! How dare you!?

  44. nanupelu says:

    I feel like I learn much more in hacking than in development… its much more didactic and easy to learn.
    Maybe big corps are sponsoring it, but why?

  45. Viking Sec says:

    Let's see that YouTube algorithm leap

  46. Rubafix989 says:

    5000$ seems pretty ridiculous for the amount of work achieved to report this bug. It's Google I doubt it would crumble for a 20k€ bounty

  47. Papa Yosif says:

    oh shit i always imagined u as kind of an asian dude.

  48. Brian B says:

    So, on what is the host running ? A vm on a server that gets booted just for your login or how do these things work. I also want to be a linux meister.

  49. Jeff Sirkis says:

    I really enjoyed this video and would love to watch more videos exactly like it.

  50. Jango1989 says:

    Great video!

  51. the Animalix says:


  52. threeMetreJim says:

    I find the easiest vulnerabilities to work on are client/server web apps with the logic carried out by some script on a server with the client side in Javascript. Found a few bugs in commercial products, the companies involved were happy to receive the bug reports for fixing, but no reward unfortunately (but I did receive a thank you). Only reward was from Facebook for quite a trivial privacy issue ($500 lowest tier bug bounty reward). I find live chat apps are usually the ones with flaws – best was a complete deletion of an app from a web page without admin privilege (with permission of the owners of the site it was hosted on), and a moderation bypass (done on the providers demo page). Another one is trying to insert HTML markup in a page when you shouldn't be able to (not enough user input sanitation that can lead to cross site scripting vulnerabilities), had a laugh on a Facebook game with that one (before letting the game developers know about the bug).

    While this is probably not legal to do, as long as you don't cause any damage and notify the providers so that the 'bug' can be fixed, I've never had anyone be upset about it – better than someone malicious coming along and causing untold havoc for anyone using whatever service has the bugs.

  53. hblaub says:

    Will this video get hit by ContentID ? 😉 just joking because the Google Cloud Shell surely appears copyrighted on company's own videos

  54. Donald Trump says:

    Good citizen bonus ++

  55. BlockLab says:

    cool video

  56. Varstahl says:

    19:22 Found a bug, his hairs are gone.

  57. dfasdfasdfasdf says:

    Implementation of a wrapper, nice stuff.

  58. ShortGiant1 says:

    Amazing video.

  59. ►What r U Waiting◄ ☺◘♪☼ says:

    google found an Apple issue and Apple start to cry cry so Google trying to teach those kids some lesson.

  60. DooYouEvenLiftBro says:

    Bruh I contacted Google about a vulnerability in YouTube that I found and they didn't even care. I contacted Riot's vulnerability program also, about being able to sign in to League of Legends without a password or username, and they want people to go above and beyond to prove to them the vulnerabilities so I'll just let them keep their flaws. In YouTube I was able to use it and play videos, without paid subscription, with my phone screen off.

  61. Silica says:

    not everyone gets to say "this video is sponsered by google"

  62. Not You says:

    I thought that was a 10 yr old in the thumbnail

  63. Markus Zeller says:

    Containers inside containers. 😁

  64. Ashvin Bhuttoo says:

    Only 5k? Its atleast worth 10 times that..

  65. Harry Baals says:

    tbh i thought it was a girl in the thumbnail, i admit my penis made the clicking choice for me. i am sorry

  66. Chet Plant says:


  67. ProXxGeo105 says:

    I have found a WebKit vulnerability granting root on iOS do apple give rewards?

  68. Kauzer says:

    Why are you standing bro, I feel like I shouldn't be sitting down

  69. Peter Alvarado Ruiz says:

    Awesome Work Dude, really appreciate your sharing this with us, well at least with me. Thank you.

  70. El Cojon says:

    Was ein Abo Plus hast du denn bitte gemacht 😂

  71. Ibrahim Kahfie says:

    Wow.Michael cera is really knowledgeable in cyber security.

  72. Osama Zaid says:

    Beautiful idea 💡 thanks to everyone who was involved in this.

  73. oldbootz says:

    Great video! I love the interview format.

  74. Zephiris says:

    i really like it. liveOverflowxGoogle is a good combination. I also find the thoughts from the researcher very insightful.

  75. Ram the Cowy says:

    Man I love your videos even as a newb who knows nothing about programming or cybersecurity, you have a way in structuring and presenting and always make them so fascinating! 🙂

  76. tomas gemes says:

    Bro this is completely EPIC! Google sponsoring. It could get even nicer though, just imagine google asking you to talk about critical historic bug reports on android, drive, youtube, search engine. IT COULD BE AWESOME!

  77. ccfBTW says:

    YouTube's algorithm 🙁 feelsbadman

  78. wtm says:

    Like everyone else i am also hoping you will get the chance to create more videos for the Google VRP, LiveOverflow! Best wishes, @wtm_offensi

  79. Lukáš Pánek says:

    This is cool!

  80. ivan hale says:

    Michael Cera is smarter than I had previously perceived

  81. Kiem says:

    Love your content, love the knowledge, love the way you transmit it 🙂

  82. Vini M. says:

    Nice video, really inspiring for people who want to find bugs.

    I wonder if you can kubectl to this cluster.

    13:33 hey, if you get access to the host, you can use strace to trace the container processes pid.

  83. Mark Yeaah says:


  84. Kantnklaar says:

    Amazing! Just $5000 though? Ridiculous, especially coming from a multi-billion dollar company

  85. dynfo says:

    I had found a bug on YouTube allowing you to delete likes/dislikes one by one using their api. Nothing urgent, nothing fancy, so I contacted their VRP with how to reproduce it. They told me that they couldn't reproduce it, adding that if the bug was indeed live, their systems would have detected it. Less than 2 days after their response, it was fixed and never heard from them again.

  86. Ahmed Jabir Zuhayr says:

    At 19:08 WTM's drawing got bald, is it a bug? :p

  87. DELTΛ sudo THC-Hydra says:

    Du bist Deutscher?

  88. Garth Humphreys says:

    Wow, thanks for sharing this content and the interview. It was very insightful!

  89. Sedit T says:

    Christopher Domas showed that simply with root access we can control every part of x86_64 CPUs by accessing the MCU… is that not the case here if one can escape this container?

  90. Anees Ahmed says:

    happy teacher day <3 you are awsome i'm big fan of you <3

  91. Yair Lopez Poveda says:

    really interesting, i hope you get to do more videos like this

  92. Martin Verrisin says:

    if you ask me, even seeing other containers you are not supposed to interact with is a security vulnerability
    – Even if nothing may come from it: They should stop the person as soon as possible, so they cannot even go deeper… – like this, they have to protect everything else behind it, rather than just that one gateway…

  93. Martin Verrisin says:

    you can strace a process in a separate container…. and that is not a vulnerability???
    Google is weird: The fact that you can escape your container is bad. They can call it what they want: it's bad.

  94. Myrmid0n_ says:

    That's really interesting and all, but I didn't understand half the stuff you said

  95. Treppi is kuhl says:

    Ich weiß nicht ob du das ließt aber ist es möglich auf dem nächstem Chaos Communication congress ein Autogramm von dir zu bekommen?

  96. Chilly Vanilly says:

    What an eye opener this is… Boy ou boy

  97. Max Gomes says:

    Had never seen you before.
    I imagined you as Asian.

  98. ÁUß Code II says:

    Hey LiveOverflow, I have been hacked and Eve left me this message. Can you help me decode this message?


  99. Bassem Ghali says:

    Hard work….well done

Leave a Reply

Your email address will not be published. Required fields are marked *