Rocksolid Light

Welcome to Rocksolid Light

register   nodelist   faq  


rocksolid / rocksolid.programming / Re: Category-Based Web

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: Handling Media
From: anonuser@retrobbs.rocksolidbbs.com.remove-10p3-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Fri, 1 Nov 2019 23:59 UTC
  To: AnonUser
The external programs may have exploits and we can not guarantee that they
don't, without auditing them ourselves (this is a hard problem)
hard problem
This is my understatement of the year.

Image viewers:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=feh
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=eye+of+gnome
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=okular
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=imagemagick
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Shotwell

Video players:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mpv
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=mplayer
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=vlc
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ffplay
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=smplayer

3D object viewers (just for shits and giggles):
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=blender

IRC clients:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=hexchat
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=xchat

Sandboxes:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bubblewrap
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=firejail

These are only the known vulnerabilities that have existed. Who knows what nastiness lies in those codebases. Programs which aren't too popular don't seem to show up and I have omitted them.

God fucking damn it.
--
Posted on RetroBBS



Subject: Re: Handling Media
From: trw@i2pmail.org (trw)
Newsgroups: rocksolid.programming
Organization: Dancing elephants
Date: Sat, 2 Nov 2019 18:51 UTC
These are only the known vulnerabilities that have existed.

If opsec is the absolute paramount parameter than restricting the content to ASCII text will go a long way imho. Dealing with all kinds of different file and stream formats is complex, and with complexity come bugs, some of which will be exploitable. Just a fact in programming.

trw
Posted on def3


Subject: Re: Handling Media
From: anonuser@retrobbs.rocksolidbbs.com.remove-xyp-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Tue, 5 Nov 2019 09:38 UTC
  To: trw
If opsec is the absolute paramount parameter than restricting the content to
ASCII text will go a long way imho.
I agree, it is the safest to just restrict the content to ASCII text, but I'm not really happy with that alone. I think a plaintext browser is far too restrictive and imo kind of pointless without other media. At minimum I would expect images to be available.

Maybe the degree of security should be controlled by the user, perhaps with different security levels:

0. low security      - "embedded" media downloaded and displayed in sandboxed "embedded" external program.
1. standard security - select formats that aren't considered "risky" (images of certain formats, maybe?) are downloaded and displayed in eandboxed "embedded" external programs.
2. high security     - ASCII text only, with media only being downloaded to disk and never opened.

There is also something interesting that I've been reading about recently: formal verification of software. In other words the software is produced using logical proofs using a proof assistant, such as Coq. Something similar is possible with Haskell, but because Haskell isn't a proof assistant (no dependent types, no totality checker) it can only be used to semi-formally verify the program being written.

Just a random thought, but maybe having a formally verified implementation of the decompression algorithm of a popular image format and an associated program would be interesting down the line.

formally verified C compiler: http://compcert.inria.fr/
Haskell "semi-formal" development: https://iohk.io/en/blog/posts/2018/06/04/semi-formal-development-the-cardano-wallet/
--
Posted on RetroBBS



Subject: Re: Handling Media
From: trw@i2pmail.org (trw)
Newsgroups: rocksolid.programming
Organization: Dancing elephants
Date: Thu, 14 Nov 2019 22:15 UTC
Maybe just a crazy thought, but why don't you just use a subset of the pdf format ? You have nicely formatted text and pictures, and you can gradually allow other media as well, if you want.
Of course you would have to exclude all the nasty scripting and and remote fonts stuff...
Posted on def3


Subject: Re: Handling Media
From: anonuser@retrobbs.rocksolidbbs.com.remove-t4y-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Sat, 16 Nov 2019 14:13 UTC
  To: trw
Hmm I'll look into it. Got myself a copy of the ISO 32000:2008 standard (PDF
1.7) from here:
https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/PDF32000_2008.pdf

I just glanced over it for now, will have to read through it in detail. There
are a lot of features I didn't even know PDF had. Though I think I would end up
with the same issues that browsers face today, even if I strip it bare:
everything being built-in and hard to replace individual components. At least
that is my line of thinking.
--
Posted on RetroBBS



Subject: Re: Handling Media with Streams
From: anonuser@retrobbs.rocksolidbbs.com.remove-lyv-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Sat, 16 Nov 2019 14:54 UTC
  To: AnonUser
Using streams or a general network or ipc based API may actually be the
preferable way to do things.

Sure, I would have to implement the basic programs first or port existing ones
(image viewer, video player, etc.), but it would allow the browser to be highly
extensible and offload security concerns from the base browser to the
individual programs which are also sandboxed per-process. It's basically the
OpenBSD way of doing security: keep the base so simple and generalized that you
can't have security issues. Everything extra beyond the base is a risk the user
has to willingly make.

How would it be if I would continue this idea to the extreme? For example, if I
were to generalize not only the network api between the browser and the
external embedded program, but also the way the browser embeds other programs
into itself, then I've essentially got a standardized file format where
everything is embedded. This would also mean that the screen space would be
divided up into blocks (think "html div" or "html block") in which the programs
would be embedded and this would also mean that even a "text block" would have
its own dedicated program which _only_ displays text.

I first thought about doing things the hybrid way with the previous embedded
idea where a text block is built in while something like an image or video uses
an external embedded program. The question is, why is a text block any more
special than an image? Why not go to the extreme and make it also an external
embedded program which displays text? The only advantage of the hybrid approach
is that it uses slightly less ram, but at the cost of extra complexity and
possibly security issues due to the added complexity (maintaining differing
ways to handle each block vs one truly generalized way).

I hope this incoherent rambling makes at least some sense :D. This may actually
be crazy enough to work well in practice...
--
Posted on RetroBBS



Subject: Re: The Modern Web
From: anonuser@retrobbs.rocksolidbbs.com.remove-ba6-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Mon, 18 Nov 2019 12:24 UTC
  To: AnonUser
As I mentioned elsewhere, using dedicated programs to the web would be
preferable for performance and efficiency reasons and there is a project that
does exactly that:

http://weboob.org/

It's written in python, but even so it's less bloated and more efficient than
the modern browser. I do not think it is _the_ way to solve the problem, but it
seems to be an interesting project nonetheless. One issue it has is that
content isn't interlinked as it is with the web, which is one major drawback.

This brings me to a similar idea that I'll try to formalize in another post.

- crowbar
--
Posted on RetroBBS



Subject: Re: Category-Based Web
From: anonuser@retrobbs.rocksolidbbs.com.remove-igd-this (AnonUser)
Newsgroups: rocksolid.programming
Organization: RetroBBS
Date: Mon, 18 Nov 2019 14:25 UTC
  To: AnonUser
Weboob.org got me thinking and I came up with an idea based on the principles
of Weboob.

With this idea, we will be dividing and limiting what "categories" of web pages
can exist. For each category of a web page we will have a dedicated program to
handle it. So it's basically like Weboob, where we have a few programs and
those interface to services.

We don't however write modules to support different websites in the sense
Weboob does, we create API's that dictate what is possible for each category
and for each category we create a dedicated program to handle it. Website
developers will have to implement those specific API's to allow the programs to
interface with them.

The problem of Weboob as I see it, is that between the programs there is no
linkability. If I am using the program which displays ASCII text, I want to be
able to click on a link inside it and let it open another ASCII text page. This
means that the programs themselves must be able to identify links on their own
_without_ extra metadata and have a mechanism to execute each other (through
the browser for example).

All these dedicated programs will then be tied together using a browser to
allow seamless tabbed usage of all programs like we have today on modern browsers.

The advantages using this approach:
* very easy to implement
* bloat-free
* anonymity and privacy is easy to guarantee
* controlled dynamic(!) content possible and also safe
* dedicated programs to handle each category
* easy to replace individual dedicated programs
* dedicated programs can be written in any language
* reduced bandwidth usage (markup not transferred)
* sandboxing individual programs possible

The disadvantages:
* less freedom for web developers, as they have to abide by category API and
don't have much room for customizations unless specifically allowed for by the API
* we _need_ to either heavily modify or write our own programs to make this work

I actually _really_ like this idea.

--
Posted on RetroBBS



Subject: Re: Category-Based Web
From: AnonUser@rslight.i2p (AnonUser)
Newsgroups: rocksolid.programming
Organization: Rocksolid Light
Date: Wed, 20 Nov 2019 02:28 UTC
AnonUser wrote:

  To: AnonUser
Weboob.org got me thinking and I came up with an idea based on the principles
of Weboob.

With this idea, we will be dividing and limiting what "categories" of web pages
can exist. For each category of a web page we will have a dedicated program to
handle it. So it's basically like Weboob, where we have a few programs and
those interface to services.

We don't however write modules to support different websites in the sense
Weboob does, we create API's that dictate what is possible for each category
and for each category we create a dedicated program to handle it. Website
developers will have to implement those specific API's to allow the programs to
interface with them.

This is an interesting idea. One thing the Freenet Project has done is provide
a simple interface to generate "Freesites". If you provide developers an easy
way to create their site, some might actually do so.

The disadvantages:
* less freedom for web developers, as they have to abide by category API and
don't have much room for customizations unless specifically allowed for by the API
* we _need_ to either heavily modify or write our own programs to make this work

I would assume only those who are interested in the project itself would create
sites, like i2p or Freenet developers write for their project out of interest
for the project itself. Others may not see any reason.

I actually _really_ like this idea.

It's very interesting!

--
Posted on Rocksolid Light



Subject: Re: Category-Based Web
From: anon@anon.com (anon)
Newsgroups: rocksolid.programming
Organization: def5
Date: Fri, 22 Nov 2019 22:47 UTC

And once you are done, don't forget to include an api for federation to news servers. :-)

Posted on def4


Pages:1234
rocksolid light 0.6.5e
clearnet i2p tor