Lecture 1

  • Same Origin Policy
  • Server app security
    • You can't control the client. The client can go and send anything they want.
  • Client app security
    • It's really easy to get a user to go to a url
  • Auditing the code you're running isn't reaallly actually feasible. There's too much changing at a time.
  • Why is security high?
    • Run untrusted code securely
    • Want high performance on low-level features and hardware access
    • APIs have evolved
    • You can't make changes to break old websites.
  • Sites can:
    • Download content from anywhere
    • Spawn worker processes
    • Open sockets
    • Many more things!
  • Review
    • HTML
    • Uniform Resource Locators (URLs)
      • Ways to specify:
        • Relative url (based off page we're currently on) <a href='september'>September News</a>
        • Full url: <a href='http://stanford.edu/news/2019/'>2019 News</a>
        • Absolute URL: <a href='/events'>Events</a>
        • Fragment URL: <a href='#section3'>Jump to section 3</a>
    • There are many HTML tags. Important ones are link, style, script.
    • JS started out as a scripting language for the browser, so it was lacking many features (modules, file storage, etc). People came along and made node so it could be used as a general purpose scripting language.
  • Many APIs aren't actually JS, they are provided by the browser. Node therefore doesn't have these (like moveWindow)
  • Readings
    • https://developers.google.com/web/updates/2018/09/inside-browser-part1
      • CPU: Does tasks in general
      • GPU: Good for graphics
      • Process: Application's executing program. The OS gives this a slab of memory
      • Thread: Lives inside the process; executes part of the process. Threads are optional.
      • Processes talk to each other using IPC (Inter Process Communication)
      • Chrome used to give each tab a process. Now it gives each site its own process (including iframes)
      • {{table}}
        • Browser
          • Controls "chrome" -- address bar, bookmarks, back/forward, network requests, file access
        • Renderer
          • Controls anything inside the tab where a website is showing
        • Plugin
          • Controls plugins used by the website (such as flash)
        • GPU
          • Handles GPU tasks in isolation (diff process because GPU handles requests from multiple apps, but draws on the same surface)
    • https://developers.google.com/web/updates/2018/09/inside-browser-part2
      • When a url is entered...
        • UI thread initiates network call to get site content. Network thread goes through appropriate protocols like DNS lookup and establishing TLS
        • Read response: Payload comes in; network thread looks at first few types of the stream if necessary. The content-type header should say what type of data it is but it can be wrong. MIME Type Sniffing can be used here, but this is tricky
        • Depending on the type of file, it gets passed to an appropriate process (renderer or download, for instance)
        • SafeBrowsing check occurs -- if it's a known malicious site, then network thread alerts to display a warning. CORB (Cross Origin Read Blocking) makes sure sensitive cross-site data doesn't get to the renderer.
        • Finally, the page renders, address bar is updated, and all other browser-relevant things are updated.
        • beforeunload runs when people leave.
    • https://developers.google.com/web/updates/2018/09/inside-browser-part3
      • What happens in the renderer process?
        • Turn HTML, CSS, JS into a webpage.
        • Parse the DOM.
        • Load subresources (images, css, js needed)
    • https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript

Referred in


If you think this note resonated, be it positive or negative, send me a direct message on Twitter or an email and we can talk. Also ping if you'd like to know the updates on this note.