225 karma · joined December 22, 2019
What if we just released a new browser that flat out refused to load any resource outside this definition?
Would sort of be like the parallel worlds of gopher and the web for a while. I think it would be interesting to have a "web fork" that was just for documents not apps.
There's a better way. It's coming.
- 2023: Non-terrestrial (or non homo-sapiens intelligent) life confirmed.
- 2023: Space/solar-system tourism or mass publicity of human space missions.
- 2024: First commercial autonomous human-like bipedal standalone android
- 2025: Geo-volvanic/tectonic/oceanic disaster on same order of magnitude as Indian ocean tsunami but not as severe.
- 2027: "Pseudo" AGI system. You can talk and interact with it and it has all the answers but it's still not quite "all there".
- 2029: A lot of people die and infrastructure damaged in war act/atmospheric/solar event.
I also build a way to archive anything you browse online so you can read it again offline as if you were still online. > 500 stars on GitHub. https://github.com/dosyago/22120
https://github.com/dosyago/22120/releases
I like multiple release channels and there's plenty of ways to install and use this.
You can download a standalone binary (Win, Mac or Linux), install globally from npm, or just clone or download the repo and run it.
I'm not sure about docker, but could you maybe give it a try and share me the docker file privately and I can decide if I like it?
If it's good then we can add it to the packages page on the repo. Sound OK? Email me at cris@dosycorp.com if you like this idea. Thank you! :)
A lot of people in this thread talked about proxies, as in "why did you not implement a proxy" or "I implemented this but as a proxy"
The main advantage I see of this approach over a proxy is: simplicity.
The core of this is approximately 10 lines of code. The reason is it can hook into the commands and events of the browser's built in Network module.
I think there's no need to build a proxy, if you can already program the browser's in built Fetch module.
I think proxies have issues such as distribution (how do you distribute your proxy? As a cumbersome download that requires set up? As a hosted service that you have to maintain and cost?), and security (how do you handle TLS?), and complexity (I built this in a couple of hours over 2 days, one of the "obligatory bump" projects added to this thread is a proxy and has thousands of commits).
The biggest problem I see is the complexity. I feel a proxy would create a tonne of edge cases that have to be handled.
I did not mind sacrificing the benefits of a proxy (it can work on all browsers, and on any device), because I did not want to run my own server for this, but rather, crucially (I feel) give people back the power and control over their own archive. Even more importantly for me is I want to just make this the easiest way to archive for a particular set of users (say, Chrome users on Desktop), really get that right and then if that works, move to other circles later (such as mobile users, or other browsers).
Anyway, thanks for your kind comment, it really encourages me to share more about this.
I read some of your comment history but I can't get a lock on who you are, but you seem pretty interesting. Do you mind sharing a GitHub or something? If not, but you'd like to continue chatting, email me cris@dosycorp.com
Thank you!
https://bugs.chromium.org/p/chromium/issues/detail?id=813540
https://cs.chromium.org/chromium/src/content/browser/devtool...
which looks like it ignores the HTTP verb and acts only on the path. I confirmed this with tests: fetch('http://localhost:9222/json/new') and fetch('http://localhost:9222/json/new, {method:'POST', body:''}) do the same thing, as does using verb 'DELETE'.
All these open a new tab. Without knowing a 128-bit target identifier, it looks like opening a new tab is the only thing you can do if someone is running DevTools.
Great question. First up, as long as you don't put --remote-debugging-address=0.0.0.0 you are only exposed locally, so the debugging endpoint can only be accessed from your local machine.
That leaves open the possibility that a web page can access that.
There's two possibilities:
- fetch('http://localhost:9222/json') which errors or is opaque because it is non CORS, or
- connecting directly to the websockets for targets, which have addresses like, http://localhost:9222/devtools/page/<128_bit_hex_string>
Interestingly, you can connect to the websocket, you just need to know the random identifier.
There are probably some DevTools zero days, but apart from those it looks like it's OK unless:
0) the identifier is not random,
1) you can get past CORS on the localhost which might be possible with an exploited extension, 3rd party software or plugin or
2) you can guess the websocket 128-bit identifier. (Guessing should only take 500 billion years. Even so 128 bits seems quite short relative to some encryption keys but there's probably a reason for that.)
Regarding 0) checking the Chromium source it appears that these ids are passed in to the constructor of "DevToolsAgentHostImpl":
https://cs.chromium.org/chromium/src/content/browser/devtool...
and are either "GUID"s or "tokens" and in the former case they are created here:
https://cs.chromium.org/chromium/src/base/guid.cc?sq=package...
and in the latter case by a class revealingly named "unguessabletoken.h":
https://cs.chromium.org/chromium/src/base/unguessable_token....
which in each case appears to rely on getting random bytes from a file descriptor to "urandom" which I think is an operating system level randomness primitive.
Once the library server is implemented, you'll be able to browse to it (localhost:8080 or so) and access your archive from there.
Nice idea on synthetic domain, that might yield another way to do.