Live data from Hacker News

Show HN: Firefox in WebAssembly

developer.puter.com

101–110 of 134 posts

Re: Show HN: Firefox in WebAssembly

#102
post #97
post #48

Earlier quoted context omitted.

>Why not route traffic through my actual browser? Because you can't. Not even an Extension is able to. Browsers don't want you to bypass their content enforcement. I wish we had at least one hacker friendly browser.

> Browsers don't want you to bypass their content enforcement I for one am happy that browsers dont let any random web page i visit port scan my internal network.

No one said any site should. Letting a site you control do it is a perfectly valid user choice. Otherwise people are stuck going through third-party proxies which is far worse.

Re: Show HN: Firefox in WebAssembly

#106

I've been waiting for this to happen. The websites that don't want you to block ads will serve you an obfuscated "inner browser" that will render their site. All your ad blockers, etc, are rendered moot. Once accessibility is solved this is absolutely going to be a thing on major websites.

If ublock origin guards the connections above, ads still won't load.

(Except embedded ads, that also show now)

Re: Show HN: Firefox in WebAssembly

#109
post #10

I'm so glad this exists, I've been considering doing something like this for a few months. I recently got a TV based on VIDAA os, a locked-down linux-based OS where everything is rendered from Web pages. It has a built-in browser that doesn't support ad-blocking (I suspect VIDAA is profiting from showing ads on the TV), and you can't install new apps unless they're Web pages. This would hopefully allow one to run Fir…

Chances are you'll run out of ram trying to run a browser inside another browser on a TV with 1-2GB ram usually.

You might have a better luck with network level ad blocker like pi-hole or adguard for eg

Re: Show HN: Firefox in WebAssembly

#110
post #48
post #23

All the network traffic from that browser is routed through a server. My IP inside that browser was in India and on CloudFlare network. I don’t particularly trust Puter. Why not route traffic through my actual browser?

>Why not route traffic through my actual browser? Because you can't. Not even an Extension is able to. Browsers don't want you to bypass their content enforcement. I wish we had at least one hacker friendly browser.

No, it is possible with extensions.

Extensions can inject headers, such as Access-Control-Allow-Origin: *, to unblock cross-origin requests. In the Manifest V3 context, however, that might require patching window.fetch and window.XMLHttpRequest.

For example,

  // content.js
  window.fetch = async (...args) => {
    const request = args[0] instanceof Request ? args[0].url : args[0]
    const config = args[1] || {}

    return new Promise((resolve, reject) => {
      chrome.runtime.sendMessage({ action: "proxyFetch", request, config }, response => {
        if (response.error) {
          const err = new Error(response.error.message)
          err.name = response.error.name
          err.stack = response.error.stack
          if (response.error.cause) err.cause = response.error.cause
          reject(err)
        } else {
          const base64Data = response.dataUrl.split(",")[1]
          const bytes = Uint8Array.from(atob(base64Data), c => c.charCodeAt(0))
          const contentType = response.headers["content-type"] || "application/octet-stream"
          const blob = new Blob([bytes], { type: contentType })

          const status = response.status
          const statusText = response.statusText
          const headers = new Headers(response.headers)
          const body = status === 204 || status === 205 || status === 304 ? null : blob
          resolve(new Response(body, { status, statusText, headers }))
        }
      })
    })
  }

  // Background.js
  chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
    if (message.action === "proxyFetch") {
      fetch(message.request, message.config)
        .then(async res => {
          const headers = Object.fromEntries(res.headers.entries())
          const blob = await res.blob()
          const reader = new FileReader()
          reader.onloadend = () =>
            sendResponse({ status: res.status, statusText: res.statusText, headers, dataUrl: reader.result })
          reader.readAsDataURL(blob)
        })
        .catch(err => {
          const { name, message, code, stack } = err
          sendResponse({ error: { name, message, code, stack } })
        })

      // Keeps the message channel open for the async fetch
      return true
    }
  })
Post reply on HN