Rocksolid Light

Welcome to Rocksolid Light

register   nodelist   faq  


rocksolid / rocksolid.programming / Media Sanitization

SubjectAuthor
* The Modern WebAnonUser
+* Re: The Modern WebAnonUser
|`* Re: The Modern Webanonymous
| `* Re: The Modern WebAnonUser
|  `* Re: The Modern Webanonymous
|   `* Re: The Modern WebAnonUser
|    `* Re: Re The Modern Webtrw
|     `- Re: Re The Modern WebAnonUser
+* Ideas for an Alternative WebAnonUser
|+* Re: Ideas for an Alternative Webanonymous
||`- Re: Ideas for an Alternative WebAnonUser
|+* Handling MediaAnonUser
||+* Re: Handling Mediaanonymous
|||`* Re: Handling MediaAnonUser
||| `* Re: Handling Mediaanonymous
|||  `- Re: Handling MediaAnonUser
||`* Re: Handling MediaAnonUser
|| `* Re: Handling Mediatrw
||  `* Re: Handling MediaAnonUser
||   `* Re: Handling Mediatrw
||    `- Re: Handling MediaAnonUser
|+* Handling Media with StreamsAnonUser
||`- Re: Handling Media with StreamsAnonUser
|+* Media SanitizationAnonUser
||`- Re: Media SanitizationAnonUser
|`* Re: Category-Based WebAnonUser
| `* Re: Category-Based WebAnonUser
|  +* Re: Category-Based Webanon
|  |`* Re: Category-Based WebAnonUser
|  | +- Re: Category-Based WebRetro Guy
|  | `- Re: PrototypeAnonUser
|  `* Re: Category-Based Webanon
|   `- Re: Category-Based WebAnonUser
+- Re: The Modern Webtrw
`- Re: The Modern WebAnonUser

Subject: Re: Ideas for an Alternative Web
From: anonuser@retrobbs.rocksolidbbs.com.remove-4d2-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Sun, 27 Oct 2019 13:12 UTC
  To: anonymous
I will post my ideas in detail when I find the time to do so. I have a lot going on right now so I wasn't able to do that.

i guess this will be part of your stacK:

http/https
tor
tcp

Somthing like this, I'm thinking:

custom protocol
Tor and/or I2P
TCP / UDP

HTTP and the way current browsers use it is what I want to avoid. I would basically remove everything from the HTTP protocol and I'm then left with something that doesn't even resemble HTTP in the slightest, so I might as well go with something custom. I'm thinking something along the lines of Gopher, but even that has indices that are not required, because it will work differently.

TLS or something similar isn't needed right now, as I intend it only to be used through Tor or I2P (at least for now). It will only be required if it gets somewhat popular and people actually want to use it on the clearnet.

I'm not going to reinvent the wheel for Tor or I2P, they are good anonymization networks that work just fine.

then on top you will parse the content and do something with it.

Yes, I'm still working out some ideas on "how" it should be done. I'll post one of my ideas on how to handle media after this.
--
Posted on RetroBBS



Subject: Handling Media
From: anonuser@retrobbs.rocksolidbbs.com.remove-cxc-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Sun, 27 Oct 2019 14:20 UTC
  To: AnonUser
Having a static web on its own with text-only would solve all the privacy and bloat issues we are having, but we would like a lot of the convenience of current browsers without the privacy, anonymity and performance issues.

This can be achieved by launching external programs which we trust, rather than having the browser handle everything. The idea isn't by all means new, and browsers were able to do this for practically ever. To view an image, you could download an image and then make your browser launch your favorite image viewer to display that image.

There is however a problem with this approach: it spawns new windows and that image is no longer part of the "document". We've also had the ability to display text and other media like images side-by-side inside the browser for ages.

What we do _not_ have, is the ability to replace our browsers internal image viewer easily. We also can not sandbox it externally, because it is part of the browser itself.


Here's what I'm proposing:


The browser that I envision, downloads media and launches an external program to open said media, but it embeds the external program (using the window manager) optionally and on demand as if they were part of the browser itself.

This has some nice properties:

* Browser becomes very lean
* Image (or media in general) viewing functionality is _completely_ separate from the browser, while at the same time it looks as if it were part of the browser to the user
* User can easily allow/disallow media entirely
* User has the ability to easily swap his image viewer (or media viewers) to a different one
* We do not have to modify existing external programs, they will work as-is with our browser
* We have the ability to optionally sandbox media independently of the browser

Note on sandboxing and Linux: if we use X11 then it's pretty pointless with regards to security, but sandboxing on Wayland could be interesting. Sandboxing would however be helpful in ensuring no data can accidentally leak over the network by removing any networking permissions the external program would otherwise have.

Note on embedding: it's trivial to embed windows in X11 and Microsoft Windows into other windows. I do not know if it's trivial on OS X, iOS and Android, which I will have to look into, as I would like the browser to also run on those.

The same idea can be applied to other media and is not limited to images, for example: video, audio, etc.

I also thought about the possible issues with this idea:

* The external programs may have exploits and we can not guarantee that they don't, without auditing them ourselves (this is a hard problem)
* The user can, at his own risk, use different programs for which we can't guarantee anything
* As mentioned earlier, sandboxing is nice but on Linux with X11 it is quite pointless with regards to security. Thoughts/criticisms/comments on this are welcome and appreciated.
--
Posted on RetroBBS



Subject: Re: Handling Media
From: anonymous@def2.anon (anonymous)
Newsgroups: rocksolid.programming
Organization: def2org
Date: Sun, 27 Oct 2019 17:01 UTC
as I would like the browser to also run on those.

this suggest the language to be used to be java, python or something like that (unless you want to maintain a separate codebase for each system).


Posted on def2




Subject: Re: Handling Media
From: anonuser@retrobbs.rocksolidbbs.com.remove-on5-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Sun, 27 Oct 2019 23:22 UTC
  To: anonymous
this suggest the language to be used to be java, python or something like
that (unless you want to maintain a separate codebase for each system).
The two languages that mainly come in question for me are: Haskell and C++. I would prefer a single codebase, but maybe I'll have to bite the bullet and go with separate codebases down the line. I did read that the developers of subsurface were able to reuse their entire core logic on desktop and mobile operating systems. I think they did it by having their core logic as a shared native library, though I did not read into the specifics.

Haskell is my preferred language because of the anal type safety and decent performance. However, I will write a prototype before I start implementing the browser to see if I can achieve my desired performance and memory usage. If I'm not able to, then I will either try something like Ivory (typesafe Haskell eDSL to generate C) or go with C++. I'm not dead set on Haskell, but I would highly prefer it.

As for the operating systems themselves:
In the beginning I'll likely start off with a Linux prototype and a Windows port shortly after I have the core functionality implemented. It will be ported to the other operating systems later down the line, getting Linux and Windows in a usable state is higher priority simply because the implementation and the ideas need to be tested in practice first.
--
Posted on RetroBBS



Subject: Re: Handling Media
From: anonymous@def2.anon (anonymous)
Newsgroups: rocksolid.programming
Organization: def2org
Date: Mon, 28 Oct 2019 06:21 UTC
Haskell is my preferred language because of the anal type safety

For anal safety use patience, a good rubber and lots of lube...lol
Posted on def2




Subject: Re: Handling Media
From: anonuser@retrobbs.rocksolidbbs.com.remove-ecr-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Mon, 28 Oct 2019 13:23 UTC
  To: anonymous
For anal safety use patience, a good rubber and lots of lube...lol

I will take your word for it, you seem to be very experienced in that matter lol.
--
Posted on RetroBBS



Subject: Handling Media with Streams
From: anonuser@retrobbs.rocksolidbbs.com.remove-10bd-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Thu, 31 Oct 2019 18:26 UTC
  To: AnonUser
With the first method I described using existing external programs to handle the media for us by launching them in a sandbox with command line parameters to open the downloaded media. This method is basically like the first, but instead of downloading the file we provide a standardized stream API to access the file and/or content through the browser.

In this situation the browser will merely act as a gateway to the media. If the browser needs to display an image, then it would launch an external program and give it a local port to connect to. From there on the program will communicate with the browser and receive the media as a stream of bytes.

The advantages of using this approach are:

* standardized way to interact with external programs, instead of using command line parameters which are program specific (would likely require "launch profiles" for external programs)
* live-media such as live streams can be easily proxied through without requiring a separate mechanism like with the first idea
* it would be easy to extend the browser to act as a transparent proxy for certain types of interactive media like IRC, through which all data is sanitized for anonymity (for example: when the user click on an IRC media link, the browser provides a local port through which the IRC client will connect through and the browser acts as a benevolent man in the middle)

The possible problems and or disadvantages I can see are:

* external program developers will have to implement our stream API for certain types of media. The chicken and egg problem of popularity is going to require us to implement support for it in external programs (extra work)
* does it really make much of a difference in the end? compared to the first idea it's basically the same but just a different method to pass on data.

I suppose this would be the overall the "cleaner" method to implement media handling, but would also require a lot more work than with the initial idea. I do not know if the amount of work is worth it in the end. Maybe extending the first idea with benevolent man-in-the-middle capabilities for certain interactive media (for example IRC) would be a more realistic approach than shoehorning everything to use a stream API.

Media sanitization can also be done with the first idea, but I'll make a separate thread for that.
--
Posted on RetroBBS



Subject: Media Sanitization
From: anonuser@retrobbs.rocksolidbbs.com.remove-qkw-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Thu, 31 Oct 2019 18:38 UTC
  To: AnonUser
What do you think about media sanitization in general?

Say our browser downloads a PDF and wants to display it. Instead of passing that PDF directly to a sandboxed external program it would first "sanitize" it. Sanitization basically means that we take the PDF and strip everything that is a possible security concern or could cause your anonymity to be compromised. (e.g. links inside a PDF)

Media sanitization isn't trivial unfortunately. You need to implement a parser for the format and also a sanitizer. You also must know how the external program could possibly cause security issues and / or identity leaks. Interactive media such as IRC can also be sanitized the same way, but in this case we must implement an IRC man-in-the-middle.

PS: This wouldn't be a replacement for sandboxing, it would be in addition to it.
--
Posted on RetroBBS



Subject: Re: Media Sanitization
From: anonuser@retrobbs.rocksolidbbs.com.remove-p8j-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Fri, 1 Nov 2019 11:47 UTC
  To: AnonUser
In retrospect, scrap this idea. We'd end up basically with complexity and bloat we don't want.
--
Posted on RetroBBS



Subject: Re: The Modern Web
From: trw@i2pmail.org (trw)
Newsgroups: rocksolid.programming
Organization: Dancing elephants
Date: Fri, 1 Nov 2019 20:12 UTC
In retrospect, scrap this idea. We'd end up basically with complexity and bloat we don't want.

my thoughts exactly. also you would increase the attack surface by far.
Posted on def3


Pages:1234
rocksolid light 0.6.5e
clearnet i2p tor