2018/Berlin/censorresist

From IndieWeb
Jump to: navigation, search

Building a Censorship Resistant Web was a session at IndieWebCamp Berlin 2018.

Notes archived from: https://etherpad.indieweb.org/berlin-censorship


IndieWebCamp Berlin 2018
Session: Building a Censorship Resistant Web
When: 2018-11-03 16:00

Participants

Notes

Current web infrastructure

  • single centralized server has 100% control
  • all the client can do is request
  • single point of failure
  • how can we design systems that might mitigate the sensorabilituy of projects today?
  • distributed web projects
  • 1.5 billion estimated sites
  • how can we make sure they stay accessible?
  • ipfs
  • only for content that doesnt change
  • peer discovery
    • behind the router so you can host the ip address
  • browsers have been passive clients that can only make request
  • p2p is not a direct request between two parties
  • ipfs is not a two party direct response relationship
  • response can come from the nearest peer holding the hash
  • mesh networkd
    • 20 requests sent until someone holding the hash returns it saying they have it
    • distributed hash table
  • single object dispensed between many different holders
    • similar to tcp/ip architecture
  • passed along until someone says that they have it
  • honey pots
  • what are the pros and cons for censorship
  • request based on hash, hash is not immutable, series of changes --> similar to git
  • relation to a browser-doesnt particularly matter
  • Beaker is a Chromium-based browser for DAT.
  • dat stream is referred to as dat archive
    • folder that contains all data of web app
  • ipfs has immutable data.
  • site that is ipfs enable can the url
  • Can retrieve data from local peers.
    • Can it be configured to only request locally?
  • access a javascript api that allows you to write new files to the folder
  • can this be synced
  • front end and back end dont make sense anymore when you have them both running in the same space
  • forking a dat archive is easy, with cryptographical signatures to differentiate between authors
  • ipfs is about immutability- dat is about changes
  • if i write something very critical about a government, the government can then blacklist my site
  • immutable content can also get hacked
    • trust being misplaced
  • does tor content play well with ipfs format?
    • its not all traffic
  • proxy p2p traffic to tor
  • will site work served from ipfs inside censored country?
  • trust is the problem no matter what
  • trust anchor
    • certificate authority (CA) infrastructure
  • trust is through domain name on regular web browser
  • out of band (OOB) key exchange
    • SSL public key and private key
  • mirrors CA problem
    • always delegating authority when trusting others
  • exposure
  • bitcoin chain contains several pieces of "illegal material" (both for certain legislative areas/countries, and for a large number of legislative areas/countries)
  • new architectures for publishing but not protecting individuals doing the publishing
    • these new architectures are very different from the status quo
  • understanding the architectual differences that keep these two worlds seperated
  • how do you bring these things together?
  • service that copy and serve through a gateway
  • filecurrency is backed by file storage services

See Also