 So hi everyone, I'll be speaking about my Google Summer of Code project that's called Privli. So it lets you share privately your emails, your messages, any kind of text that you would transfer on the web. So I'll just start with the presentation. So I'll talk about some problems that we face on the internet these days. We actually have to trade personal privacy for accessing the latest technologies. So there are a bunch of good technologies available like Gmail or Google Hangouts or Facebook, but a lot of time these websites do crunch personal data. These might be for processing or showing you different advertisements or things of that sort. So we find that the user's content is at risk. So user has to trade their content for some kind of advertisement or other things of that sort. So a lot of times our data also gets hacked. So these are some of the links that you can go to and these were published in all the newspapers, the Guardian, the New York Times and we see how our personal life information is traded by companies and our data is regularly hacked or this is leaked accidentally or sometimes due to some reason. We also see how companies have a surprising power when we give them all of our data. So we come up with a solution that's called Privli. So I'll just show you guys a small demo of how Privli works. So yeah, so this is let's say a GitHub private repository and I want to share some of the comment with only some of my mentors or my collaborators. So what I do is here I can see my collaborator that's Sean Gregor and here it's me. So rather than just leaving a comment directly which GitHub can then access later, I will use the Privli extension that I have installed and then encrypt the data and then send it back to my friend. So I just type the message here and then I do a right click and then I use the context menu that's called Privli New Message. So I'll just go ahead and do that. So the first time you log on to Privli it makes you log into your account. So you have an account where you can store all your information, your messages and you can later see that for history purposes. So I'll just go ahead and log in with my credentials. Yeah, so right when I log in I see my message that was there on the GitHub bar comment. So here I see also things like time until the content is destroyed. So I can have, it's like a paste bin so I can have it for infinite amount of time or I can limit it to get it destroyed after let's say seven days or a week, two weeks or so I'll keep it as 28 days for now and I'll save my message. So right when I save my message, my message, the comment right now will get replaced by the Privli link. So this is the Privli link which GitHub doesn't have any idea about what it is. So it is completely secure from our point of view. So this is what other people who don't have the extension will see. But if we have our extension, I'll just go ahead to preview and you'll see that the Privli extension actually works internally and shows us our message. So if I go to preview, it loads the Privli message and then you get the message back. So this is what all of my team will see again. So you see how the experience is very seamless. You just post a comment, you do a right click and you do a new message and then others can see the message very seamlessly. So I'll go through the roadmap. First I'll talk a bit about myself, more about Privli and how Privli works internally, some of the technical visions. And then I'll talk about my project that was to create a Safari extension. And then finally we'll have some time for questions. So a bit about myself, I'm Sambuddha Vasu. I was part of the Google Summer of Code project in 2014-2015. I was a mentor for Google Code in 2015. I study in Triple ID Hyderabad, that's in India. I'm still in my third year of undergrad and I grew up in Dubai. So our solution also Privli lets you share your data anywhere without giving the host site all the content. You can grant or revoke your access to your content to anyone at any point of time. It also gives the content creator ownership of their data and it gives you more than privacy, it also helps you with security. So some of the things that Privli does not do. So one might ask, why should I trust Privli? So Privli does not use or sell your data. It does not give your data to third party companies for any kind of access and it also lets you own your own content because you are the content creator. So moving on to the internals of Privli, this is how Privli works internally. So we found out that the answer for privacy is actually encrypting the data. And so Privli extensions encrypt your data and then send it to a server. So the server has no knowledge of what your data is. And the server sees only a mixed alphanumeric text. So you can store your data anywhere without losing your privacy. You can either store it on the Privli content servers or you can have your own content server and mention the server IP address or the host names on the Privli extension. So a technical vision of how Privli extensions work. They use data indifference to create a notion of injectable applications. So we actually inject some kind of an iframe where we find a Privli link. So you can put an iframe and have a source as anything, a text, a video or image or audio file, anything that's supported by HTML5. So we can have full web applications that are injected into the context of other web applications. So this will work theoretically on any website. Applications are scoped to the data and not the layout of the different websites that we have currently. And properties are simplified and usable across web. So one major thing that Privli uses internally is zero bin. So zero bin is kind of like a paste bin, but in a more secure way. So it encrypts your data and then sends it to the server and then decrypts it on the client side. So for the cryptography, zero bin uses SJCL, that's stand for JavaScript Crypto Library for encrypting and decrypting your data. So this is how Privli works. So we have the browser here that the user wants to enter any message. Let's say Facebook Messenger or Gmail or GitHub. So you get a random 256 bits key that is generated on the client side. And then using AES encryption, your message is encrypted. And then it is stored into the server. And you also see a URL which has your identifier and it has a key. Pay attention to how the key is after the format identifier. That's nothing but the hash symbol that is seen here. So on the decryption side or the client side, when you want to fetch the message back from the server, once you get the encrypted data back, it again decrypts it using the key that we have. And all this is done in the client side. So many a times people have questions, how can I trust that it is all doing in the client side? How can we have a proper trust over this? Can you show us some examples? So I actually went to using Google Chrome and I typed this URL on my browser. And you can see how I have a pribly inject one as the key on my web browser. Whereas if you open up console, you won't see that key in the get request that are being sent to the server. You can also verify this using Wireshark, those of you who are used to Wireshark. You can just do a port 443 or port 80 and then you can see the different packets that you have. So this is all done in the client side. So the server has no knowledge of what your data is. So pribly allows you to have different browser extensions so that users don't have to go through all of these internal things. So the browser extensions scan for web pages for specially formatted hyperlinks. These are actually the pribly links that we generate on our side. And it injects the pribly link into an iframe that is then served locally. So application has potentially support. They can support any web implementable feature. So these are any of the features that are there currently on HTML5. So we have our browser extensions for Google Chrome, Mozilla Firefox and Apple Safari. So my project was to create the extension for Safari. So I'll go ahead and talk a bit about that. So the Safari extension is ported over from the Chrome and Firefox extension. It extends the pribly applications. So we have different repositories for all of our extensions. And we have a main repository that's called pribly applications which are then leveraged into all the different extensions. So it uses content scripts. So content scripts are usually some JavaScript files that run into context of any of your web pages. So once you have any of a web extension, these extensions have something known as content scripts which will search or do anything that you have mentioned in these functions. And the extension is now available on the Apple Safari extensions gallery. So anyone using Apple Safari can go ahead and download and use that. So Safari extensions also have an idea of a popover. So these are anything that you see that comes down when you click extension. So you can see here that I have a pribly extension and I have different options. I can do a start injecting. I can view my history of all the messages. I can post a new message. I can view the options for the extension or also I can get a help page. So right now we see a Facebook profile which just has some pribly links, but the user cannot actually go ahead and see. They have to click the links and then they get redirected to the page. So once I start injecting, you can actually see the content right over there. So you don't need to actually move ahead to some other website. It's as seamless as possible. It'll be really, like it won't be much of a worry for you because you'll be seeing it wherever the links are present. So I'll go ahead and talk about some of the challenges that I faced while developing the extension. So one major challenge was with content security policy. That's called CSP. So many a times I saw that websites like GitHub or Twitter, they have a CSP saying block any of the iframes which come from this host or which come from this host. So an example is these are example of the response headers. So you have a key that's the content security policy and the value is something like frame source self. So if I have this on Twitter, this will allow me to inject iframes only with a host name of Twitter. So this is different from how different browsers implement content security policies. So I tried Safari doesn't actually have a very open source kind of a tool. So I tried and went over to the Apple developers program and tried creating some tickets, but you don't get much of a help from the Apple developers program. So for testing the Safari extensions, we use, we have unit tests and we also have integration tests. So the unit tests are written in Jasmine. Jasmine is a JavaScript library or a framework for creating unit tests. And then tests are run with the help of Karma. Karma is just a JavaScript framework for unit test running. So the integration tests are run with Selenium. So these are Selenium testing that you do for browsers. You have different web drivers and then you can do a bunch of different things like navigate to a website, see the contents, see the DOM elements that are present and things of those sort. So we also have continuous integration on the GitHub repos. So each time someone creates a pull request on the Privly Safari repo, the tests are run on Travis CI and Travis CI internally runs a bunch of tests and then they internally fire up some tests on Source Labs. So Source Labs helps you with testing all of those Selenium tests. And finally, once all my tests run, I get a generated report of all the code coverage and these are then exported to Coveralls. So I can have a basic overview of which files need to be tested. Am I breaking any of the file or things of those sort. So this is currently the extension and some of the future development that me and my mentors are working on is to share images, audio and everything else that is supported by the HTML5. So we went over and we did a development version of how things will look ahead. So here we see that my mentor had sent me a message which is just a Privly link and once I start my Privly extension, I can see that this is actually a visualization which I can interact with. So I can click and interact with any of the things. So this lets you see how Privly extensions can be used for visualization or also for images or the audio files that you want to send to your friends. So those of you who found this project interesting can contribute to the project. We have our official repos on GitHub, so that's github.com slash Privly. We are also active on free.irc and our channel is PoundPrivly and our official website for more information is priv.ly. Those of you who are interested in getting to know how Privly works or things of that sort, you can go to github the issues and then you can start with level zero issues. So we have different bugs, like for beginners we have level zero and then level one, level two and things like that. So yeah, that's all from my side. Do you guys have any questions? Yeah. I just wish I got it right. The key itself is in the link of the hash. Yeah. So can I please just link it and say in a Facebook or whatever, they had to, they could technically decrypt it if they know how Privly decrypts it. Yeah, they can technically decrypt it by seeing how Privly decrypts it. But the point that I want to mention is the key is never sent to the server. So I had shown an example here. So if you open up your console and you type the Privly extension on the web address, you will see that the key is never sent to the server. So you can see a post.f2.json but the key is not sent to the URL, request URL. You can also start via shark and see the packets read the packets you won't be seeing the key transfer to the server. Sure, but I guess the key is in the fifth presenter. Yeah. Does this work on a mobile device as well? Yeah, we do have an Android application right now. It is also there on the GitHub repose. So you can go ahead and check that out. Sorry? It's called Privly. Yeah, just Privly. This was the Android application. It was actually one of the GSOC projects last year. So that was GSOC 2014. As we've seen, you said you showed actually a Privly account which I haven't logged in to the official stores. So the user who is going to see, like, say, forward is going to see, does they have to kind of log in through the message? No, they don't have to log in. It's from the person who's posting the message so that they have track of all the different messages that they had sent. So if you want to, let's say, share a link which you have already shared with other people, you can just log on to our Privly website and see the message and then share that exact link to someone else. So the user who's seeing it for the first time will just see your Privly link. And if he doesn't have the extension installed, he'll just click on the link and go to one more page. That's the Privly page. And then he see the contents there. But if he has the extension already enabled, then he sees the content on your mail itself. Basically, instead of storing the actual content in, like, Facebook or something, and he's just getting stored in Privly? Yeah, it's getting stored in Privly or you can also have your own content servers and basically store them there. So you can mention in the browser extensions that hey, I want to store my encrypted data in my server, so you just mention it there and we store it on your server. There are links on the priv.ly official website of how you can set up your own content servers. If I set up, supposing I set up my own content server, and I post a Privly link onto GitHub. Does my friend who's the intended audience need to configure his browser to know that this is my content server as well? No. So that's basically you storing your data, but if anyone wants to see your link, it'll get redirected internally. So they can either have the extension or off and they can still see the message that you have sent. We haven't actually, I mean, I haven't actually worked with a lot of botnets and using the Privly links, but I'm sure you'll find some answer about that on the IRC channel, IRC channel. You can also join our mailing list. If anyone with the Privly extension can see the content, right? Yeah. So that's not anyone, let's say I have a Privly extension on and even you have your extension on, but if you don't send me any Privly links, I won't be able to see. But if you send me a link, which has the key also, then I'll be able to view your message. Even if I, so we have not made it mandatory to have a Privly extension installed on your browser. So even if you don't have it installed, you can still click the link and it'll take you to a new tab, which you can click. So what it means, I can't say I only want certain people to see. We are working on that. You mean to say, I want to send it only to a group of people who are later like managed, let's say I want to send it only to my team. Things of those sort. Yeah. So we are still working on that and let's see, we'll probably have it in the next release, hopefully. I guess I can post the link without the key and duplicate the key. Yeah, you can also do that. You can just send the key to some of your friends. So you just send your URL and then after the pound symbol, the fragment identifier, you don't send it to all of the people. You just send it to some of your friends that you want them to see. My question was based on, because if I have a problem or somebody kind of posted, I can still kind of find a link and when I do that, I can still get the message. So of course Facebook is not storing it. At the end of the day, I can still kind of get to the message. Yeah. Well, one benefit of having the extensions as I felt is it makes your whole experience as seamless as possible. So you don't have to actually go through new tab and like change tabs and all those kind of things. You just post your message and then you see it right there itself. Are there any other questions? Has this triggered any security warnings or security in any of the outside environment? Till now, we haven't faced any of those kind of things. But there are some drawbacks of the Safari extension of because how Safari handles the CSP policies, content security policies. So for now, a few things like Twitter have you, they let you inject iFrames only from Twitter itself. That's the same, that's there for Twitter. So the Safari extension does not work well with Twitter. So you can still see the link and you can click the link and it'll take you on to the next or a new tab. But it works great with other websites and it does work with Chrome or Firefox. So, what are you wondering if any of the triggers will be in the text of the services across sites? We haven't implemented that till now and we haven't actually come across those kind of things. So we have our alpha release, the beta release on GitHub, you can download it from our downloads page and we're still working on a bunch of different things. So we'll be working on those things this summer. That's all. Any other questions? Thank you. Thank you. Thank you.