Pribox

pribox

Summary: This is the backstory of how we built pribot.org . There is a Wired article about the project already. This article provides our story of what went behind the scenes. Whenever someone asks me what I work on, I find nothing better than a single link to a YouTube series of 9 hours filming an actor reading Amazon Kindle’s terms and conditions. Yes, you read it correctly: 9 HOURS. Here is the trailer: And this is a link to the full series . Hopefully, you’re still with me at this early stage and you didn’t get lost in an endless spiral of similar videos recommended by YouTube, such as people streaming themselves reading privacy policies of , , and e, for hours. Google Facebook Appl Actually, the privacy policy, the equally annoying sibling of terms and conditions, is the subject of this article. Have you thought how long it would really take to read all the policies for services we use per year? That would be according to a research by in 2008. 201 hours McDonald and Cranor So given the choice between this unpaid, exhausting task and anything else, it’s no wonder that people prefer spending time fulfilling their yearly exercising goals, reading an amusing book, or just relaxing. This is even when they hear frightening stories of what’s inside privacy policies (like and ). this this Researchers have tried to make these policies simpler, primarily by manual methods, like websites offering of their policy, inspired by nutrition labels. Approaches relying on the wisdom of the crowd have received good traction too (like the “ ” project). Yet, these attempts didn’t scale due to the huge manual effort and human expertise involved. standardized versions Terms of Service; Didn’t Read Fixing Privacy Policies: the Backstory 🛠 Two years ago, my colleagues and I wrote a for a workshop on the future of privacy notices. paper In it, we proposed a vision for turning privacy policies into a conversation via a chatbot called . PriBot Let’s admit it: 2016 was the year of chatbots, and we were — shamelessly — motivated by the hype. After all, the best interface . Right? is no interface Our idea was that you could ask PriBot about any privacy policy like you ask Siri for the capital of Ivory Coast . PriBot would then respond in real time with an answer from the policy itself. (spoiler: Yamoussoukro) Fast forward ⏩ Twenty months later, we have taken our vision to fruition in a new , in which we first show how we realized the goal of automated Question Answering for privacy policies. This is a collaboration between (yours truly), , , , and . research paper Hamza Harkous Kassem Fawaz Rémi Lebret Florian Schaub Kang G. Shin Karl Aberer As our first research outcome, we’re introducing PriBot to the public, via a chatbot that you can converse with right now at : pribot.org/bot PriBot in action On the way to build PriBot, we had a surprising byproduct, which even has the potential to make a wider impact: we built a general system for automatically analyzing privacy policies using machine learning. We call it Polisis. gives you a glimpse about of privacy policy, like the data being collected, the information shared with third parties, the security measures implemented by the company, the choices you have, etc. All that without having to read a single line of the policy itself. Polisis We’re releasing Polisis too at . You can alternatively download its or to analyze websites in a click. pribot.org/polisis Chrome extension Firefox addon Polisis in action To our knowledge, Polisis is the first system to provide such in-depth automated analysis of privacy policies. Who is this for? 👩‍⚖️🕵️‍👨‍💻 We have three audiences envisioned: We designed PriBot and Polisis to be highly intuitive for the general user who is interested in the privacy aspects of the sites they use. General users: We envision that the technology powering Polisis could be used for large-scale analysis of privacy policies by regulation agencies. For example, in our , we used Polisis to show how privacy certification companies (such as — now TrustArc) have been highly permissive with businesses. Regulators: paper TRUSTe A lot of research has studied apps and websites in an automated way based on their code, their embedded scripts, or on what they share over the network. A missing piece of the puzzle is what these apps promise in their privacy policies. We hope our work can empower researchers with new insights from the policies’ angle. Researchers: To that goal, we would be glad to collaborate with regulators, researchers, and the general industry. Feel free to if you are interested. reach out No Magic Pill Now to the research part! You might say: “couldn’t you do the above by combining a few APIs or open source projects? Didn’t IBM Watson beat humans at answering “Jeopardy!” questions? And why couldn’t you use commercial services like ?” Microsoft QnA Maker The answer is that such systems are not magic pills. If they are trained on specific domains, like insurance questions, they can be rarely adequate for others. If they are trained on a general domain, they suffer when tested with specific problems. Imagine asking the question: “ ” around a privacy policy. Almost every QA system will favor the answer “ ” over the answer “we use your location for customizing our service.” Obviously, the second is the better answer. Yet, this is not easy to get. do you gather my address info? for your info, we work hard to address your issues What makes things harder is that there are no public datasets of questions and answers about privacy policies waiting to be trained. So traditional approaches to this problem were not the way forward. A Hierarchical Approach 💤 We took the other way around. We focused on solving the problem of automatically labeling segments in the privacy policy, producing . Then we leveraged that solution for the QA problem, producing . On a high-level, our approach for automatically labeling segments was as follows: Polisis PriBot We first trained a model on 130K privacy policies that we collected. Unsupervised Learning step: word embedding We then trained a hierarchy of 22 classifiers (each being a neural network) for labeling the different aspects of the policy. We relied on the valuable OPP-115 dataset from the for this part. Supervised Learning step: Usable Privacy Project : if you just read these steps, and you try to reproduce the results, that will lead to a horrible performance. Our discusses the devil in the details, which lead to a high accuracy, from data preprocessing to classifier selection, etc. Spoiler paper How can we move from classification to QA? Let’s say you had a question “Do you share my info?”. To get an answer, we first break the policy into . Each segment is a candidate answer. Then, we rank the answers by their similarity to the question. small standalone segments The similarity is measured by seeing which answers receive “close” labels to the question. To get these labels, we pass both the question and the answers through our classification hierarchy. How to define “close” is also important. For example, questions are frequently broad. You don’t want to frustrate the user by with close, but generic answers. Hence, we came up with a new similarity algorithm to account for this issue (details in the ). paper Examples We Love Hopefully, by now you are willing to give our tools a try. Head over to to see them both in action. pribot.org And to get inspired when you stress-test PriBot, you can check the following examples. Here, PriBot works although there are no common words between the question and the answer: …or when our hands get sloppy, and we misspell a few critical words (you can thank for this): subword embeddings PriBot also notifies users when there is a contradiction in the potential answers: …and it tries to not appear stupid when presented with irrelevant questions: Likewise, you can give a go, and you can a few examples below: Polisis With Fitbit’s policy, you can get an overview of what data the company collects. By clicking on “Analytics/Research”, you can see all the data being collected for that purpose, with the options you get. You can also see that Fitbit shares health information with third parties in the second tab. Hovering over the link will give you the exact evidence from the policy itself. If the policy gives you choices to mitigate data collection, you can see these choices in the dedicated tab, along with the links to opt-in or opt-out. Finally, if there is no information about a certain aspect in the policy, we give an explanation on why this is the case. We hope you enjoy playing with these services, and we welcome your feedback. We know well the limitations of this technology. Hence, we do not claim that the results are legally binding or are completely accurate. Yet, we believe that this a great step forward on the road to Make Privacy Policies Cool (I’m tempted to end the sentence with ‘Again’, but they were never cool before 😀 )! And thanks for reading! You might also be interested in checking my other articles on my Medium page: _Read writing from Hamza Harkous on Medium. Postdoc at EPFL, Switzerland; working at the intersection of Privacy, NLP…_medium.com Hamza Harkous — Medium … or my website: _Personal website of Hamza Harkous_hamzaharkous.com Hamza Harkous’ Site

We Gave Privacy Policies an AI Overhaul, and You’ll Never Have to Read Them Again!

I read the whitepaper so you don’t have to. What is Tor? The Onion Routing Protocol (TOR) was designed by the US Navy in the mid 1990s at the U.S Naval Research Labatory[0]. The pre-alpha version of Tor was released to the public in September of 2002 [1] and the Tor project, the company that maintains Tor, was started in 2006. Here is a quote from the paper titled “Tor: The Second-Generation Onion Router” on what Tor is in a nutshell: Tor is a circuit based low-latency anonymous communication service [2] The core principle of Tor is “onion routing” which is a technique for anonymous communication over a public network. In onion routing messages are encapsulated in several layers of encryption, analogous to encapsulation in the OSI 7 layer model [3]. It is called onion routing because onions have layers and this networking protocol also has layers. The resulting ‘onion’ (fully encapsulated message) is then transmitted through a series of nodes in a network (called onion routers) with each node peeling away a layer of the ‘onion’ and therefore uncovering the data’s next destination. When the final layer is decrypted you get the plaintext of the original message. The original author remains anonymous because each node in the network is only aware of the preceding and following nodes in the path (except the first node that does know who the sender is, but doesn’t know the final destination). This has led to ‘attacks’ on which the NSA runs servers in order to attempt to be the first and last nodes in the network. If the NSA server is the first node, it knows where the message is from. If the NSA server is the last node, it knows the final destination and what the message says. [4] Overview Onion Routing is a distributed overlay network designed to anonymise TCP-based applications like web browsing, secure shell and instant messaging. Clients a path through the network and build a where each onion router in the paths knows the predecessor and the successor, but no other nodes in the circuit. choose circuit Packets flows down the network in fixed-size cells which are unwrapped by a symmetric key at each node and relayed downstream. The notion of a symmetric key comes from Symmetric-Key Encryption Algorithms. Symmetric-Key Encryption Algorithms, a detour In Symmetric Key Encryption the same key is used for both Alice (sender) and Bob (receiver) as opposed to public key encryption where these keys differ. This makes it faster and easier to use than Public Key encryption, but this also causes two problems: The key needs to be stored securely Transfer of key may not be secured. If a third party figures out the key, either by attacking the transfer of the key or some other method they will be able to decrypt all communications encrypted with this key. Symmetric Key encryption is also much less computationally expensive than public key encryption, which is useful in a network like this. is a set of cryptographic protocols based on algorithms that require two separate keys: Public Key Cryptography Public-key — Which is public and visible by others Private-key — Which is private and meant to be kept secret. These two keys are mathematically linked. In public key cryptography the use of the public key is to encrypt plaintext and the use of the private key is to decrypt encrypted text. This means that anyone can encrypt plaintext for a specific person but only that person can decrypt it. The two keys are very large prime numbers. Assume q and p are two separate and equally large prime numbers and then n = pq. n is used to encrypt the message and p and q are used to decrypt the message. This works because factorisation is hard to compute. Given a very (very) large number, find the factors of that number which are prime numbers. Often times the numbers are in hexadecimal. Digital Signatures Another useful tool of cryptography to know is digital signatures. Digital Signatures use public-key cryptography. A digital signature is a digital version of a physical signature. Often times you can say you have cryptographically / digitally signed a document. Only the person with the private key can produce valid digital signatures which allow them to sign a document alot more securely than a physical written signature. Alice wants to digitally sign a message, m. In order to do that Alice must have: Alice then uses a signing function to produce a digital signature: The internals of the signing function isn’t necessary to know. The function takes a message, a private key and it will produce a digital signature. exact Anyone can use the public key to verify a digital signature: If anyone knows how to put spaces in trueorfalse (in mathjax) I will greatly appreciate the help! I say that a signing function isn’t necessary to know however if you want to learn a few go ahead. The reason I haven’t added them to this document is because someone from 2–3 years time might read this and signing functions could be completely different. Tor itself Tor requires alot of users to create anonmity and thus if Tor was hard to use users wouldn’t adopt it so easily making it less anonymous. Because of this, the usabillity isn’t just a design choice of Tor but a . If Tor isn’t usable or designed nicely, it won’t be used and thus it won’t be secured. security requirement Tor has therefore had to make some design decisions that may not improve security but improve usabillity. Disadvantages Tor is not a completely decentralised peer-to-peer system like many people believe it to be. If it was completely peer to peer it wouldn’t be very usable. Tor requires a set of directory servers that manage and keep the state of the network at any given time. Tor is not secure against end to end attacks. An end to end attack is where an entity has control of both the first and last node in a path, as stated earlier. This is a problem that cyber security experts have yet to solve, so Tor does not have a solution to this problem. Tor does not provide protocol-normalisation like Privoxy or the Anonymizer, meaning that If senders want anonymity from responders while using complex and variable protocols like HTTP, Tor must be layered with a ﬁltering proxy such as Privoxy to hide differences between clients, and expunge protocol features that leak identity. [2] Tor does not hide the identity of the sender. In 2013 during the Final Exams period at Harvard a student tried to delay the exam by sending in a fake bomb threat. The student used Tor and Guerillar Mail (a service which allows people to make disposable email addresses) to send the bomb threat to school officials. [5] The student was caught, even though he took precautions to make sure he wasn’t caught. Gurillar mail sends an originating IP address header along with the email that’s sent so the receiver knows where the original email came from. With Tor, the student expected the IP address to be scrambled but the authorities knew it came from a Tor exit node (Tor keeps a list of all nodes in the directory service) so the authoriies simply looked for people who were accessing Tor at the time the email was sent. Onion Routing So given the network above we are going to simulate a very basic onion routing protocol. The laptop on the left is the sender and the server rack on the right is the receiver. So we start off by encrypting a message with 3 layers of encryption (Tor typically uses 3 nodes, so therefore 3 layers of encryption are needed) The first layer is stripped off on the first machine. Something important to note here is that every machine only knows what the predecessor is or what the sucessor is, it does not know what the final goal is unless it is the last node in the path. As it travels down the path, more and more layers are stripped away. The second (middle) node does not know where the message originated or where the final destination is. The final node knows what the message is and where it’s going, but it doesn’t know who sent it. The computer then reads the content of the message which might be “connect me to Facebook” and it then connects to Facebook and receives a message back as a response. Because the node doesn’t know where the original message came from, it sends it back through the network to the predecessor and says “pass this back through the network”. But before doing this, it adds it’s own level of encryption back. Eventually the original node receives a fully encrypted packet containing the response from Facebook. Because the original node has both private and public keys it can fully decrypt the message. One of the key properties here is that once a node decrypts a layer, it cannot tell how many more layers there are to decrypt. It could be as small as 1 or 2 or as large as 200 layers of encryption. The first node knows who sent the message but it doesn’t know what the message says because it is encrypted. The last node knows what the message says but it can’t tell where it came from. How is a circuit created? Each machine, when it wants to create a circuit, chooses the exit node first, followed by the other nodes in the circuit. All paths in the circuit obey these rules: We do not choose the same router twice for the same path. We do not choose any router in the same family as another in the same path. (Two routers are in the same family if each one lists the other in the “family” entries of its descriptor.) We do not choose more than one router in a given /16 subnet. We don’t choose any non-running or non-valid router unless we have been configured to do so. By default, we are configured to allow non-valid routers in “middle” and “rendezvous” positions. The first node must be a Guard node. A guard node is a privileged node because it sees the real IP of the user. It’s ‘expensive’ to become a guard node (maintain a high uptime for weeks and have good bandwidth) Something important to note here is that Tor uses the Diffie-Hellman algorithm to set up session keys between the user and onion routers. Diffie-Hellman Diffie-Hellman is a way of a shared secret between two people in such a way that the secret can’t be seen by observing the communication. You’re not sharing information during the key exchange, you’re creating a key together. generating Now for some basic knowledge on Diffie-Hellman, taken from here I come up with two prime numbers, and and tell you what they are x y You then pick a secret number ( ) but don’t tell anyone. Instead you compute and send that result back to me (we’ll call it ) a A I do the same thing, but we’ll call my secret number and the computed number . So I compute and send you the result. b B Now you take the number I sent you and do the exact same operation with it. So that’s . I do the same operation with the result you sent me, The cool part here is that the answer I get at step 5 is the same answer you get at step 4. It comes down to a cool property of modulo components: Tor Hidden Services In a traditional network you have a definite input and a definite output. You know where your data is going. In a Tor Hidden Service you input some data but no outside force can see where it’s going. It is possible to communicate with a server without the user or the server knowing who eachother are. When a server is set up on Tor to act as a hidden service, the server sends a message to some selected Onion Routers asking if they want to be an introduction point to the server. It is entirely up to the server as to who gets chosen as an introduction point and it doesn’t matter who is chosen. The introduction points know that they are going to be introducing people to the server. The server will then create something called a hidden service descriptor which has a public key and the IP address of each introduction point. It will then send this hidden service descriptor to a distributed hash table which means that every onion router will hold some part of the information of the hidden service descriptor. If you try to look up a hidden service the introduction point responsible for it will give you the full hidden service descriptor. The key for this hash table is the onion address and the onion address is derived from the server. The idea is that the onion address isn’t publicised over the whole Tor network but instead you find it another way like from a friend telling you or on the internet (addresses ending in .onion). So almost every single onion router will have minimal knowledge about the hidden service unless they explicitly want to find it. If you want to access an onion address you would first request the descriptor off of the hash table and the descriptor has, let’s say 4 or 5 IP addresses of introductory nodes. You pick one at random and you’re going to ask the introduction point to introduce you to the server and instead of making a connection directly to the server you make a rendezvous point at random in the network from a given set of Onion Routers. You then make a circuit to that rendezvous point and you send a message to the rendezvous point asking if it can introduce you to the server using the introduction point you just used and then it says “I want you to send a message, X, to the server”. The rendezvous point makes a circuit to the introduction point and sends it the word X and its IP address. The introduction point sends the message to the server and the server can choose to accept it or do nothing. If the server accepts the message it will then create a circuit to the rendezvous point. The server sends the rendezvous point to the server and the rendezvous point looks at both messages and if they’re the same then it will then act as another hop on the circuit and connect them directly. Another important thing to note is that every single Tor packet (called a cell) is exactly 512kb and they are all encrypted. Tor does this so people cannot guess that larger cells are images / media. In short, a hidden service works like this, taken from : here A hidden service calculates its key pair (private and public key, asymmetric encryption). Then the hidden service picks some relays as its . introduction points It tells its public key to those over Tor circuits. introduction points After that the hidden-service creates a , containing its public key and what its are. hidden service descriptor introduction points The hidden service signs the with its private key. hidden service descriptor It then uploads the to a (DHT). hidden service descriptor distributed hash table Clients learn the .onion address from a hidden service out-of-band. (e.g. public website) (A $hash.onion is a 16 character name derived from the service’s public key.) After retrieving the .onion address the client connects to the DHT and asks for that $hash. If it exists the client learns about the hidden service’s public key and its . introduction points The client picks a relay at random to build a circuit to it, to tell it a . The picked relay acts as . one-time secret rendezvous point The client creates a , containing the address of the and the , before encrypting the message with the hidden service’s public key. introduce message rendezvous point one-time secret The client sends its message over a Tor circuit to one of the , demanding it to be forwarded to the hidden service. introduction points The hidden service decrypts the with its private key to learn about the and the . introduce message rendezvous point one-time secret The hidden service creates a , containing the and sends it over a circuit to the . rendezvous message one-time secret rendezvous point The tells the client that a connection was established. rendezvous point Client and hidden service talk to each other over this . All traffic is end-to-end encrypted and the just relays it back and forth. Note that each of them, client and hidden service, build a circuit to the ; at three hops per circuit this makes six hops in total. rendezvous point rendezvous point rendezvous point _Support the content you love. Buy a Coffee for Brandon Skerritt with Ko-fi.com_ko-fi.com Buy Brandon Skerritt a Coffee. ko-fi.com/hacker _Go to paypal.me/BrandonSkerritt and type in the amount. Since it's PayPal, it's easy and secure. Don't have a PayPal…_www.paypal.me Pay Brandon Skerritt using PayPal.Me References [0] — [1] — [2] — [3] — [4] — [5] — [6] — http://www.onion-router.net/Publications/JSAC-1998.pdf http://archives.seul.org/or/dev/Sep-2002/msg00019.html http://fermatslibrary.com/s/tor-the-second-generation-onion-router http://ieeexplore.ieee.org/abstract/document/1094702/ https://cyber-peace.org/wp-content/uploads/2013/06/Attacking-Tor_-how-the-NSA-targets-users-online-anonymity-_-World-news-_-theguardian.pdf http://www.thecrimson.com/article/2013/12/17/student-charged-bomb-threat/ https://www.youtube.com/watch?v=QRYzre4bf7I

Stories, News & Mentions about PRIBOX

Pribox’s Stories on HackerNoon