Blasta and XMPP Integration to synchronize browser data Topic is solved

[Schimon]

Greetings!

My name is Schimon and I am a co-founder of project Blasta.

Blasta is an collaborative annotation management system (i.e. bookmarks manager) which purpose is to make bookmarks accessible from anywhere.

The experiment of Blasta has been successfull and I intend to write an extension for a Qt browser in order to integrate it gracefully into HTML browsers.

I advise to stongly consider to utilize the XMPP platform as a system to synchronize browser data, including bookmarks, history, tabs, cookies, password etc.

XMPP?

XMPP is the messaging and presence protocol.

The same XMPP of the PaleMoon conference from a decade ago? jabber@conference.palemoon.net

Yes. There is no mistake!

Please. Watch the video presentation for the technicalities or visit these resources:
- https://blasta.woodpeckersnest.eu/help/ ... mpp/pubsub
- https://blasta.woodpeckersnest.eu/help/ ... pp/atomsub

Code:
https://git.xmpp-it.net/sch/Blasta

Video:
https://video.xmpp-it.net/w/cfozoUeVLFbBFMCCSCJ1Dn

Instance:
https://blasta.woodpeckersnest.eu

Resources:
- https://portal.mozz.us/gemini/woodpecke ... owsers.gmi
- https://github.com/jarun/buku/discussions/795

[Schimon]

I have knowledge in ECMA Script (i.e. JS), yet I do not develop in XUL.

However, please inform me whether I can contribute JS code to implement this propsed synchronization feature.

[Moonchild]

Not sure what you're suggesting here. We already have a synchronization client built into the browser. You are free to write an extension to interface with your proposed service.

Documentation is pretty thin on how Blasta is supposed to work aside from "using PubSub" to store and retrieve data on an XMPP server. What are the security considerations? How is the user's browsing data protected (i.e. how is privacy of data ensured)? How is it stored? Assuming encryption: how are encryption keys handled? In what way is this better than other "cloud storage" solutions operated by a third party? What service guarantees are there for users?

[moonbat]

Also, how does an instant messaging protocol become useful for browser synchronization?

[Moonchild]

Also, how does an instant messaging protocol become useful for browser synchronization?

XMPP has server-storage extensions to the protocol. I'm assuming it's using those in some way -- not what it was designed for but wouldn't be the first time a protocol is being used for something completely outside of its design scope.

[Schimon]

Documentation is pretty thin on how Blasta is supposed to work aside from "using PubSub" to store and retrieve data on an XMPP server.

This is a summary.
https://blasta.woodpeckersnest.eu/help/ ... mpp/pubsub

All the technicalities are specified at XEP-0060 and XEP-0163

What are the security considerations?

I did not think of it yet. I suppose the same considerations for Libervia, Movim and Blasta.

How is the user's browsing data protected (i.e. how is privacy of data ensured)?

Data be protected by a permission management system.

XEP-0060: Publish-Subscribe
https://xmpp.org/extensions/xep-0060.html

4.5 Node Access Models
https://xmpp.org/extensions/xep-0060.html#accessmodels

How is it stored?

Data is stored on XMPP account storage.

XEP-0163: Personal Eventing Protocol
https://xmpp.org/extensions/xep-0163.html

Account storage (i.e. PEP) -> Node Name -> [Item ID, Item ID, Item ID, etc.]

schimon@palemoon.org -> Tabs -> [Tab 1, Tab 2, Tab 3, etc.]
schimon@palemoon.org -> History -> [Link 1, Link 2, Link 3, etc.]
schimon@palemoon.org -> Bookmarks -> [Bookmark 1, Bookmark 2, Bookmark 3, etc.]

Assuming encryption: how are encryption keys handled?

There is no storage encryption yet. I do not know whether it is necessary

In what way is this better than other "cloud storage" solutions operated by a third party?

It is better, because XMPP is:

1) Lighweight, and the smallest of XMPP servers (Prosody) would require 40MB of RAM for routine activity of 10 - 20 accounts.

2) Anyone can establish an XMPP server everywhere.

3) It is easier to implement for other browsers and consequently be a standard for data synchronization.

What service guarantees are there for users?

I did not understand the question. Please rephrase this question.

[Schimon]

Also, how does an instant messaging protocol become useful for browser synchronization?

I have wrote about it in the post that I have published.

PubSub

XMPP is known for its extension system known as XEP.

Two decades ago, a new extension known as XEP-0060: Publish-Subscribe was created and is extensively utilized, today, for content publishing, file sharing, encryption and various of other uses.

Source: https://portal.mozz.us/gemini/woodpecke ... owsers.gmi

[moonbat]

I did not understand the question. Please rephrase this question.

He means do you offer any commitment to offer reliable service for the servers or is it 'use at your own risk' ?

[Schimon]

I did not understand the question. Please rephrase this question.

He means do you offer any commitment to offer reliable service for the servers or is it 'use at your own risk' ?

I intend to write an extension to another browser software which I use, so I will comment in it.

The software itself would be reliable, and the service should also be reliable, provided that the server is reliable.

If you use your own server, then the service would be of at most reliability.


P.S.
XMPP has been proven to be reliable. Please see projects Libervia, Movim and Blasta.
Blasta has some issues, but are of server side. Anything else, in regard to XMPP itself, works as expected.

[Moonchild]

All the technicalities are specified at XEP-0060 and XEP-0163

Yes, but it's not clear how Blasta uses these extensions for its purpose. If it is using PubSub, then you'd be putting pivotal weight on that extension's authorization model, since PubSub is designed primarily for publicly disseminated information (i.e. newsletters and the like) and locking that down to just the author is definitely not intended use.

I did not think of it yet. I suppose the same considerations for Libervia, Movim and Blasta.

I'm not familiar with any of those.
Keep in mind that this would be dealing with people's private data: browser sessions, history, browsing data, potential passwords, etc. Security considerations should be absolutely at the forefront of this, not an afterthought.

Data is stored on XMPP account storage.

XEP-0163: Personal Eventing Protocol
https://xmpp.org/extensions/xep-0163.html

Account storage (i.e. PEP) -> Node Name -> [Item ID, Item ID, Item ID, etc.]

schimon@palemoon.org -> Tabs -> [Tab 1, Tab 2, Tab 3, etc.]
schimon@palemoon.org -> History -> [Link 1, Link 2, Link 3, etc.]
schimon@palemoon.org -> Bookmarks -> [Bookmark 1, Bookmark 2, Bookmark 3, etc.]

There is no storage encryption yet. I do not know whether it is necessary

Unacceptable.
Nobody but the end user should be able to access the stored data. Encryption is required, and encryption should be set up in such a way that nobody aside from the end user (not even the server admin) has access to this data. Storing everything in plaintext in an XMPP service instance is ridiculous.

XMPP has been proven to be reliable.

It's been proven to be reliable as a messaging protocol, yes. But the issue here is not the protocol itself, but what is being built on top of it. As far as I can see, that is problematic here, as important things have not been given attention (or even thought). Yes, it's theoretically possible to make a single-user publishing node that can only be accessed by that user -- at significant server overhead. Building on top of that that a publisher is also a subscriber and not having a clear way described how this will be dealing with conflicts, e.g. 2 browser instances having updated data to push, etc. is a lot more complex which I don't see documented anywhere. As mentioned before the proposed server storage isn't secure. Additionally, leaving up in the air who exactly is supposed to be running these XMPP server instances doesn't give me any reason to think this was thought through at all. You expect us/me to spin up a public XMPP instance for storage in an insecure manner while I'm already running a Pale Moon Sync (weave) server out-of-pocket for Pale Moon?...

[jobbautista9]

Looking at the project it does seem to only deal with bookmarks, which don't necessarily have to be private. Since Blasta seems to be intended to publicly aggregate every participating user's bookmarks, I'd say encryption is not needed here strictly for that purpose. I can imagine a browser extension that will talk XMPP to the user's configured Blasta server every time a bookmark is added or touched.

As a replacement to Sync 1.1/Weave however? Nope, not a chance.

[Schimon]

Wait!

The Blasta system is:

1) An annotation management system (private and public nodes).
2) A collaborative annotation sharing system (public node only).

The PuSub specification has rules of what nodes are private and what are semi-private and what are public.

Blasta only aggregates nodes that are public.

Blasta manages three nodes: (1) Public (2) Private and (3) Read.

The nodes Private and Read are private.

The node Public is public to all.

Please. Watch the video. There are a few seconds about this concern.

Blasta also has a settings panel to set nodes Private or Read as a default.

Rest assured, that the nodes that will be involved for synchronization will be PRIVATE ONLY and be acessed ONLY BY THE ACCOUT owner respectively!

Blasta is nothing more than an example for realizing utilization of browser bookmarks from anywhere with the mean of an XMPP account.

P.S. Movim has implemented an interface to selectively set access model permission to node items.

The Blasta idea and the further idea of synchronizing browse data is currently a work in progress.

[Schimon]

Nobody but the end user should be able to access the stored data. Encryption is required, and encryption should be set up in such a way that nobody aside from the end user (not even the server admin) has access to this data. Storing everything in plaintext in an XMPP service instance is ridiculous.

Encryption is possible. It is not planned yet, because I didi not even try to encrypt PubSub node items.

[Moonchild]

Looking at the project it does seem to only deal with bookmarks, which don't necessarily have to be private. Since Blasta seems to be intended to publicly aggregate every participating user's bookmarks, I'd say encryption is not needed here strictly for that purpose. I can imagine a browser extension that will talk XMPP to the user's configured Blasta server every time a bookmark is added or touched.

So, you're perfectly fine with your bookmarks (which can include credentials in URLs, depending) being publicly aggregated? Bookmarks do give an unknown observer a lot of information about your personal browsing habits, especially if you use them extensively -- it's like a curated form of your browsing history (so actually even more accurate than browsing history to know interests)
Regardless, OP stated that it would include open tabs and history as well...

[Schimon]

First

I did not think of it!

Indeed. A URL can include credentials.

Code: Select all

https://username:password@URL

It would be good to make Blasta to ignore such URLs or automatically set them as private.

Thank you for the hint.

This issue has been reported https://git.xmpp-it.net/sch/Blasta/issues/17

Second

There is a specification to embed content as Atom Syndication Format into PubSub node items (Atom Over XMPP).

There are a couple of specifications to manage this data (XEP-0277 and XEP-0472).

I wanted to do the same for bookmarks system which has not yet been decided, and only one developer (asciimoo of Omnom) has participated in the discussion to attempt to standartize a bookmarks database.

Yet, I can still propose a new XEP for bookmarks and further update it over time.

I have created an HTML interface merely to ease to demonstrate of storing bookmarks on an XMPP account, and while I have further developed it for the scheduled Berlin XMPP Meetup, it has further developed into the Blasta collaborative system, which was not my original intention.

The purpose is merely to manage browser bookmarks over XMPP, and do so privately.

The Blasta system is an additional system and can be further utilized by anyone who is interested in a collaborative and public system, while the private functionalities remain intact.

Third

1) Again. No one has ever implemented a system which is specifically dedicated for storing browser bookmarks over XMPP.

2) This system does not have an XEP neither a proposed XEP, nor even a draft for an XEP.

3) Utilizing XMPP to also store history and tabs is a new idea which I have thought of, after observing more on the idea of managing browser bookmarks over XMPP.

[jobbautista9]

So, you're perfectly fine with your bookmarks (which can include credentials in URLs, depending) being publicly aggregated?

Hmm, it might be wiser for a theoretical browser extension to be limited in when and which bookmarks it syncs then in that case, yeah. Maybe just sync a single specific bookmarks directory intended for Blasta...

Anyway I think it's fine if the bookmarks are just like music and stuff. I think at the end of the day Blasta is just like any other link aggregator like Reddit and Postmill.

[Moonchild]

Honestly, I just have the feeling this is reinventing the wheel (or several wheels, in fact) just to synchronize browser data across several devices. If you'll have to create a protocol extension (or several) just to have it do what you want it to do for one specific use-case, then the protocol is simply just not a good match for your purpose and you should consider something else. Creating a proprietary protocol for it would be less work and headaches than trying to push through a new protocol extension -- on top, adding single-use protocol extensions dilutes the XMPP protocol. Just because something is extensible you should ask the question if you should, even if you can, if there's no greater purpose/use for such extensions.

[Schimon]

So, you're perfectly fine with your bookmarks (which can include credentials in URLs, depending) being publicly aggregated?

Hmm, it might be wiser for a theoretical browser extension to be limited in when and which bookmarks it syncs then in that case, yeah. Maybe just sync a single specific bookmarks directory intended for Blasta...

Anyway I think it's fine if the bookmarks are just like music and stuff. I think at the end of the day Blasta is just like any other link aggregator like Reddit and Postmill.

I agree with your assessment.

[Schimon]

Honestly, I just have the feeling this is reinventing the wheel (or several wheels, in fact) just to synchronize browser data across several devices. If you'll have to create a protocol extension (or several) just to have it do what you want it to do for one specific use-case, then the protocol is simply just not a good match for your purpose and you should consider something else.

I in tend to create an extension (i.e. XEP) for bookmarks. It is based on XEP-0277 and is almost identical, yet it is intended for a different use-case.

I do not know yet about browser data such as history, tabs, passwords etc.

Creating a proprietary protocol for it would be less work and headaches than trying to push through a new protocol extension -- on top, adding single-use protocol extensions dilutes the XMPP protocol.

How so?

Just because something is extensible you should ask the question if you should, even if you can, if there's no greater purpose/use for such extensions.

I think, that utilizing an open and standard protocol (i.e. XMPP) for this task will prove to be a good solution to synchronize data across browser and news reader software.

[Moonchild]

I think, that utilizing an open and standard protocol (i.e. XMPP) for this task will prove to be a good solution

You completely missed what I was trying to get across.

• XMPP as-is is not a solution for this, let alone a good one.
• Writing a protocol extension (that has to be supported by all relevant clients and servers) is diluting XMPP (i.e.: it will become less "standard" the more extensions you tack on).
• I don't know what the current procedure is to have a new XEP approved/vetted and implemented, but you should be aware that your "idea" will be scrutinized in the XMPP community because it will generate additional work and complexity for a lot of people.
• Secure, complete protocols/APIs already exist for browser data synchronization

You're just wasting time at this point. If you feel driven enough to write a new XEP, a sync extension and a server instance implementation to deal with it, be my guest. You have all freedom to do so - If the result is not sufficiently secure, though, you'll have a hard time getting people to use it.