Comment by soapdog | Hacker News Reader

Comment by soapdog | Hacker News Reader

Parent Full thread

Hey! I made that patch! :-D

so basically the explanation is simple. There is a whitelist of protocols you can have your WebExtension take over.

If the protocol you want to control is not on that whitelist such as an hypothetical "catgifs:" protocol, you need to prefix it like: "web+catgifs" or "ext+catgifs" depending if it will be used from the Add-on or by redirection to another Web page. This makes it inconvenient to use with lots of decentralization protocols because in many other clients we are already using urls such as "ssb:" and "dat:" (eg, check out beaker browser). In essence this allows us to implement many new cool decentralization features as add-ons now that we can take over protocols, so, you could be in Firefox browsing the normal web and suddenly see a "dat:" link, normally you'd need to switch clients to a dat enabled app, now, you can have an add-on display that content in the current user-agent you're using.

Still, there is another feature that we need before we can start really implementing decentralization protocols as pure WebExtensions, we need both TCP and UDP APIs like we had in Firefox OS (as an example, Scuttlebutt uses UDP to find peers in LAN and its own muxrpc TCP protocol to exchange data, DAT also uses UDP/TCP instead of HTTP).

I have been building little experiments in Firefox for interfacing with Scuttlebutt which can be seen at:

https://viewer.scuttlebot.io/%25csKtp9VmxTjJoKy17O7GA6%2F3S8...

https://viewer.scuttlebot.io/%25uBev5w8m8iZGVbQDo9fpr%2BCXLB...

I hope to start a conversation in the add-ons list about TCP and UDP APIs for WebExtensions soon :-)

Decentralization and safer protocols are needed. Plain HTTP and even HTTPS are really not the best one could come up with. There are better alternatives, but using them is not always easy. So, thanks a lot for your work on making that easier!

Thanks a lot for the kind words! :-) talking about safety and integrity, have you seen how Scuttlebutt works? Check the secret handshake part of:

https://ssbc.github.io/scuttlebutt-protocol-guide/#handshake

In essence, your connection to a given peer is encrypted in a way that only you both have the keys, even if someone breaks that key (such as the peer being a bad agent) it would not compromise your connection with other peers as they will use different keys. It is quite an awesome protocol.

It's nice but the fact that you can never delete a message in your feed means that it doesn't really work as a social media protocol. Some people see that as a feature since it is theoretically uncensorable, but that's not how humans like to interact.

I have been using patchwork[1] as my main social network client for scuttlebutt. In my current experience, the fact that messages are not removable makes me more careful when writing and has led to much better and more meaningful interactions on the network.

Also remember that a message being in the feed doesn't mean it is displayed. Scuttlebutt is quite flexible, there are clients that have support for "chess messages" so their users can play chess, patchwork doesn't support those messages so I don't even see them. There is git-ssb[2] which allows people to host and contribute to code directly inside the feed, not all clients show these messages but they are all there.

New messages could be added for flagging a message id as deleted and clients could honor them and not display that message anymore, they would still be on the feed, much like in version control systems we still have access to deleted files (if no one rewrites history).

I enjoy how permanent things are there because as a side-effect it causes people to care more about the ecosystem and culture as those are permanent stuff you're putting out there. Check out this essay "the future will be technical"[3] about the culture on scuttlebutt, you'll see it is quite different than other social networks, but I agree with you, your experience may vary and what I consider an advantage, others may see as a reason not to use.

[1]: https://github.com/ssbc/patchwork/ [2]: https://github.com/noffle/git-ssb-intro [3]: https://coolguy.website/writing/the-future-will-be-technical...

Erasure of data, on demand, is a requirement of GDPR[0], which becomes law in Europe on 25 May 2018.

Note that erasure of the data is required, not just its display.

IANAL, but the above appears to be contrary to GDPR.

[0] https://en.wikipedia.org/wiki/General_Data_Protection_Regula...

I am not a lawyer either, but doing a quick read on the scope, I found in first phrase:

  "The regulation applies if the data controller (an organization that collects data from EU residents) or processor (an organization that processes data on behalf of data controller e.g. cloud service providers) or the data subject (person) is based in the EU."

And this might not apply as there is no data controller, organization or company. You data is on your computer and it replicates that data to friends and friends of friends. There is no cloud or service involved, it is from one machine to the other, I believe someone that has real knowledge of legal matters and p2p should chime in. I am also a bit lost regarding this.

Surely that means that the people who replicate it from your ("your friends" and "your friends of friends") would be required to delete the (personal) data?

So I could require anyone inside the EU to delete any mail they received from me? (I'm in the EU)

Yeah, email was the first thing I thought of as well. Surely that doesn't apply.

I contacted an e-chum who is a lawyer specialising in the field of IT, IP and media law [0]. He pointed me back to Article 17 of the Regulation, Right to erasure ('right to be forgotten'), which is contained in [1].

This states that:

"The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay ... where .. the data subject withdraws consent on which the processing is based..."

Paul also expressed the view that: "It’s certainly been written in a way that should require systems to be created to allow for the deletion of personal data, though!"

That intent is key here. Basically: if someone asks you to remove their data and you refuse (or fudge, etc.), then don't be surprised if the EU comes knocking.

[0] https://www.uea.ac.uk/law/people/profile/paul-bernal

[1] http://data.consilium.europa.eu/doc/document/ST-5419-2016-IN...

Thank you very much for the contribution. The decentralized web projects sound really exciting and it's awesome to see support from Mozilla.

However, I find the concept of the scheme whitelist pretty strange in context of WebExtensions.

Of course it makes sense that http:, https:, data:, blob:, etc should be off-limits for extensions. But on the other hand, I'd think that the primary use-case of registering protocol handlers in extensions is to handle existing links - something that the ext+/web+ rule seems to be particularly designed to disallow.

Apparently, the actual handler whitelist for WebExtensions can be found at [1]. It looks pretty... arbitrary?

For example, it's amazing to see that magnet: irc:, ssh: and gopher: are on there, but then why not ftp:, ws: or even steam:? There could be some useful extensions intercepting those as well.

Likewise, while the inclusion of scuttlebutt, ipfs etc is very good news, what makes them eligible now that didn't make them earlier?

Generally, I'd like to know by what process is that whitelist managed and what are the criteria to get on there.

(I understand it's derived from the official HTML5 whitelist [2]. To be honest, that one looks even more arbitrary - but of course has different security considerations, as it defines an API for the open web. The two lists also seem to have some differences, as e.g. gopher: isn't on the HTML5 whitelist while openpgp4fpr: is not on the extensions list.)

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/ma...

[2] https://html.spec.whatwg.org/multipage/system-state.html#cus...

Is there a chance we could get MAFF: (and MHT:) protocols as well and let our web-extension handle those (single-file archived web pages if anyone wondered)?

This would allow us to (again) associate the Firefox browser with for example .maf files and have them displayed in the browser via the extension. (I'm sure there must be thousands of archived pages out there that currently are a hassle to view - it would be great to get support for those).

Would it be possible to implement ssh:// ?

I know it's theoretically possible to make some browsers respect ssh:// urls. But to actually do so requires a lot of work.

Presumably this is to avoid some security problem that I'm not immediately aware of. Or maybe just plain caution?

Theoretically? Yes. (You'd need to add it to the whitelist, but you could do that.)

Practically, though, you still have the problem of actually making the connection; there's no API for that yet.

Ah, OK. That's probably the sticking point.

I was thinking it could just invoke some external program.

That sounds great! Could you give us a pointer how to add a protocol like freenet: to Firefox (or ext+freenet:, as long as its not in the whitelist)?

Please excuse the inappropriate question, but this one has been bugging me for many years: will there ever be some kind of session manager on Firefox Mobile that can save and recall your browsing session (a group of tabs) to/from a local file, similar to how OneTab or MySessions are working?

Reply on news.ycombinator.com