search

beakerbrowser / beaker

An experimental peer-to-peer Web browser
https://beakerbrowser.com/
MIT License
6.75k stars 545 forks source link

Extensions? #230

Open zeke opened 7 years ago

zeke commented 7 years ago

@pfrazee is it possible/easy to install Chrome extensions in Beaker?

pfrazee commented 7 years ago

Hey @zeke. No, and I'm planning not to support them. Extensions slow down browsers, introduce attack vectors, and would require a lot of support from the beaker team. I'd prefer to focus on expanding the Web application model, because that's where I think a rich userland should be - not in extensions.

zeke commented 7 years ago

I would like to attempt use Beaker more regularly even as my default browser, but the lack of support for extensions hinders my chances of making the jump. I am pretty fond of things like my ad blocker and password manager.

expanding the Web application model

can you elaborate on this a bit?

zeke commented 7 years ago

As an exercise, I compiled a list of the extensions I would be sad to live without:

That said, I'm curious to hear more about how Beaker might help enable a browser world where things like this don't need to exist.

pfrazee commented 7 years ago

We actually have an open issue to get adblocking integrated by default. I'm 100% behind that. I'm not quite as sure about 1password but, maybe.

To explain a bit about where this is going, I have a WIP blog-post draft (Please don't share!): https://gist.github.com/pfrazee/658058fe9d1325931cc4381275e0a130. I've also written a bit more about it in https://github.com/beakerbrowser/beaker/wiki/App-Scheme

Rather than modifying applications by browser-extensions, I want to encourage people to fork Web apps and change the code directly. That will be a more reliable solution than extensions, since it allows devs to change the actual app logic, rather than appending new code and/or modifying the DOM.

In the interest of customization, Web Applications should also interoperate via APIs such as web-intents, service workers, or general RPC, and the endpoints of those interop-APIs should be configurable.

1password and adblockers are examples of something that really do need to be implemented with the browser (in the core code, or as extensions). 1password modifies all the password inputs, and adblockers modify lots of different requests and element behaviors.

But there's a lot of extensions that are designed to modify web apps, and perhaps by also using configurable web-components, we can get really fine-grained with customization.

zeke commented 7 years ago

👍 Thanks for the extra context. Love the concept.

pfrazee commented 7 years ago

@zeke btw, octolinker and npmhub... nice recommends, you just made my life so much better

zeke commented 7 years ago

:)

wesleytodd commented 7 years ago

I am maybe a bit biased, as the only extension I keep enabled by default is a json formatter, BUT I am in agreement with @pfrazee that a better model in the long run would be interoperable applications, as opposed to browser extensions that modify existing web apps.

I think this is a difficult path going forward for Beaker, and this issue deserves serious attention. For now, I just wanted to put in my support for this approach, with hopes to think more about this in the future.

EDIT: Also would like to add that I AM using Beaker as my default browser.

zeke commented 7 years ago

I AM using Beaker as my default browser.

👍

Just saw this: https://blog.brave.com/loading-chrome-extensions-in-brave/

serapath commented 7 years ago

@zeke do you say the way brave supports chrome extensions works for beaker too?

@pfrazee I am considering for quite some time already to make Beaker Browser my main Browser, but I'm using a web extensions I don't want to miss. I agree with the reasons you mention above. I also stumbled upon something you wrote earlier here: https://gist.github.com/pfrazee/658058fe9d1325931cc4381275e0a130

One of the main important things you mention we should be able to do is:

  1. Modify sites, and share the modifications with other users.
  2. Integrate applications in ways not predicted by their developers.

Which I totally agree with and in that context what you say above makes a lot of sense.

  1. Switch apps without leaving behind our content or network.

This third one you mention is actually what drives me to use web extensions. My content and network is always relevant to me regardless of the app I'm currently using. It's my personal context and I'd like to work with it, maybe update it while using one or many apps.

To make it simple, I use different tools and I need access to those no matter which app/website I'm currently visiting.

Example:

  1. I'm a heavy user of bookmarks and would like to make a "improved" version of the standard bookmark bar. Its great that this bar (my data) is always present no matter which website i'm currently on. Not everyone uses the bookmark bar - maybe their needs are different
  2. I'm using certain social networks and messengers others might not use, so I like to have extensions that support sharing and communicating with ppl through those extensions no matter what app/website I'm on.

I think the 1password and adBlocking needs are again use cases - it's user specific and at least to me it's relevant, that "my solution" works the same across webapps.

I also saw: https://github.com/beakerbrowser/beaker/wiki/App-Scheme If that is meant to solve the above "use cases" i'd be happy if you could tell me how I should do it. It's not entirely clear to me how to have a team chat/sharing experience and with others while surfing through multiple apps/websites, how to always have my data visible next to the app i'm currently using (think: bookmarkbar)

pfrazee commented 7 years ago

@serapath The app scheme spec is now dead. Instead check out these three specs:

What we're talking about now is implementing a subset of the WebExtensions API, with the main goal of just disabling content-scripts (injections). If that works, then it's just the adblocker and password manager that aren't covered, and I think we can build those into the browser directly.

jcalfee commented 7 years ago

Please consider, browser-side private key signing (like a wallet) is much safer if an extension has no access by default.

ilyaigpetrov commented 7 years ago

Please, to an adblocker and password manager add the third essential: non-dat-protocols censorship bypassing tool, which depends on censorship techniques used per country. Specifically, I hope something like this (provider can't distinct traffic to site A from traffic to google.com) to be implementable in beaker. Or maybe a VPN configurable right inside beaker with a few clicks. Dat protocol and anticensorship support will make beaker popular in censorship abused countries.

blittle commented 6 years ago

I came across Beaker from a tweet by @staltz https://twitter.com/andrestaltz/status/980483816606392321

As a front-end dev, for me to actively use Beaker as my main development browser, I need extension support. Specifically the React (and other) developer tools extension.

blahah commented 6 years ago

I am using Beaker as my default browser right now and the biggest pain point is logging into sites or services. I'm using lastpass macOS systemwide app but it requires copy-paste. @pfrazee how close are we to being able to build integrations with such apps that could enable, for example, password management within Beaker?

@blittle I was going to approach this by having a separate environment for doing beaker app development: an electron app that integrates the APIs that Beaker exposes in different contexts, but also allows for all the dev tools. This avoids compromising the security model of Beaker itself. If anyone has better ideas I'd welcome them 👍

RangerMauve commented 6 years ago

With regards to password management, applications should start using the new Web Authentication API for storing credentials.

Beaker doesn't currently have a Credential Manager installed, but this shouldn't bee to crazy to implement in the future.

Even though I agree with the idea of a hackable web, extensions are really important for use cases where you can't just fork a website to add a feature. The react dev tools, for example, are the only things keeping me from using beaker when doing development.

brettz9 commented 6 years ago

@pfrazee : There are so many desirable ways in which the core browser can be desirably extended beyond injections and intents. Whether it is having the URL bar showing domain parts differently, having themes, having a search box, expanded status bar, tab grouping, tree style tab, overriding the file browser, etc.

Please, we've already experienced the dismissiveness of the browsers who sold out users in abandoning the power of XUL in favor of a very watered down WebExtensions (which, even with Native Messaging, is quite limited). As much as extending HTML APIs is desirable, unless you're going to design these to allow all privileged add-on APIs which allow for core features like hidden HTML windows, Node privileges, access to manipulating tabs, etc., you're not going to meet the awesomeness that Firefox add-ons used to be (FWIW, my old AsYouWish add-on took this approach in trying to restore XUL to the Firefox SDK until Firefox's changes broke it).

The ingenuity of add-on developers can no doubt meet many of your user's needs, and I'd expect that the initial work required for adding an add-on system would pay off for Beaker because of the reservoir of talent that would jump on board, no less with those I've seen disenfranchised for having been abandoned with no good viable replacements in sight to their power add-ons.

Besides this, making API into core could better force consideration of your own design choices. And if being fairly comprehensive in what is allowed to be modified, this could actually end up an improvement on XUL in allowing more granular privilege consent.

You're not going to come up with a short exhaustive to-do list of cool, core-modifying add-ons (except to your own taste perhaps) because there is no end to what could be done, and many a great XUL add-on have already been done and yet are now gathering dust because those at the top decided that they knew best about what others needed.

pfrazee commented 6 years ago

A lot of our ideas for Beaker have evolved since this thread started, while some have not. Let me give my current thinking.

I'm not 100% sure about how we'll approach extensions, or which APIs we'll eventually include, or if we'll end up including page injection APIs. Maybe we will include them; maybe we'll implement the ful Web Extensions API. Sometimes it's better to just start with the simple old solutions and build from there.

What I do know is that we want a Web applications model which is safer and more powerful. To some degree, I think that means merging the extensions world and the website world so that you can "Install" an app and give it a lot of power: things like registering for intents, adding buttons to the navbar, and running persistent background processes. (The library API is the beginning of a step to that kind of power, but I am not satisfied by it in the least.)

I also know that we can make a more powerful plugin system by getting apps involved in their own extension. If we create APIs for apps to load and run HTML/CSS/JS plugins, then we give apps the opportunity to structure the exchange between themselves and their downstream. The app can say, "I display comments and I have a toolbar for inserting markup: does the user have any plugins for adding actions to the toolbar?" That creates potential for a much more powerful plugins ecosystem.

Maybe we need APIs to modify core behaviors like monitoring & modifying all traffic, or injecting JS into every page you visit. My hope is that we could improve the core behaviors so that userland hooks don't need to adopt that kind of risk, but I recognize that's an ambitious goal, and it comes with downsides.

I'm trying not to dismiss your requests. I'm just trying to find a new approach that fixes some of the old.

brettz9 commented 6 years ago

Thanks for your reply... I hope I didn't sound too strident, but I was wary of the message getting lost...

Since some users want power and some want safety, and since browsers can't make things entirely safe anyways, I think the best solution is to allow informed consent and choice, with safe defaults (including, for example, turning off even the ability for websites to ask for APIs until the user whitelists them; yes, the user can be socially engineered and manipulated into doing this at their own risk, but so can they be socially engineering to install a dangerous WebExtensions NativeMessaging add-on or any other executable).

Consider Native Messaging within WebExtensions. This allows some power back to websites. My current implementation of AsYouWish (bundled at the moment with WebAppFind) uses native messaging to communicate with Node so that websites which ask for Node or WebExtensions permissions can get it if the user approves.

(Rather than inventing my own wrapper for every API, I currently just allow eval, but it'd obviously be far less risky to allow more granular privilege requests.)

While browsers may feel like they have created an entirely safe bubble for users (and they have made their job of review easier by dumbing everything down), this washing of hands by giving NativeMessaging doesn't really prevent dangerous add-ons (as my description of AsYouWish should testify), but it also unfortunately didn't deliver on allowing one to have full control over the browser either (e.g., one can't manipulate the DOM of the browser for which APIs do not exist).

And since the main browsers seem to only really care about what gets to their stores (and Native Messaging just appeases their detractors), they do not persist in creating APIs which give a lot more power, nor do they enhance Native Messaging further so that, e.g., devs could at least build Node extensions without special build tools.

On the other hand, no one should want to completely go back to the bad old days of XUL as far as there being informed consent to users of the unlimited powers extensions could then do...

As far as making more power within HTML and apps able to make themselves extensible...I actually do tend to favor them being able to do anything to modify the browser and foregoing add-ons completely if they can actually do everything. Why? Because it requires less of a developer; they don't need to worry about packaging--just progressively enhance their own site to do something powerful, and allow users the choice of only giving permission for some power on a one-off basis, so that, while they trust the site to do something powerful, they don't need for that power to be applied every time they load their browser (or visit the site).

So to me the absolute ideal would involve...

  1. HTML APIs to manipulate the browser progressively, restartlessly, in any way imaginable (optionally persistently so), and without requiring add-on packaging steps, with intelligible informed consent to the user of what they can do, and equally importantly, how such privileges can be abused by unscrupulous sites, once permission is given (since people may not understand "make request cross-origin requests" until you show how this can be dangerous to themselves, e.g., XSRF)...
  2. Reasonable defaults which prevented sites from either getting permission or even asking for permissions without whitelisting (by site and/or protocol, or even by specific page in case very different apps are on the same origin), and possibly customized builds (e.g., for businesses or parents) which baked in the rejection of certain powerful APIs (or otherwise ensured sandboxing). And of course the ability to revoke permissions by site or protocol.

Best of both worlds, in my view...

samuelmaddock commented 5 years ago

Hey @pfrazee, just dropping in here to mention that I'm working to improve Chrome extension support in Electron with my current wip electron/electron#17440. Hoping that one day it'll be easy for Electron-based browser developers to add support for extensions.

pfrazee commented 5 years ago

@samuelmaddock Appreciate it! I'll keep an eye on that

LWFlouisa commented 5 years ago

Currently trying to use it as my dafault. The main extensions I use are https everywhere, ublock origin, privacy badger, and stuff like that.

Would there be a way to introduce these without introducing attack vectors?

Side note: I think I figured out roughly what's going on with the create new button: even when it never seems to go anywhere, sometimes it will create a dummy archive that seems like it's present, but isn't actually there.

RangerMauve commented 4 years ago

Here's a cool library that injects extension support into electron based browsers

https://github.com/sentialx/electron-extensions

Might be relevant to look into at some point

RangerMauve commented 4 years ago

Also looks like first class extension support in Electron is progressing pretty well getferdi/sponsors-only#1319

Offbeatmammal commented 4 years ago

just as a 2c, I've been trying Beaker as my primary browser for a few days (love the concept) and the only extension I really miss is LastPass (I know I could probably install their desktop app and get around it that way) but I do notice the difference between browsing in Beaker vs using Brave with integrated ad blocking...

I'd argue against integration of a password manager into Beaker for the same reason I don't use Chrome or Brave to store my passwords... I want a degree of vendor independence (for instance, I'd never use Safari for passwords as I'm split between my Mac, Windows, and an Android phone)

marcussacana commented 3 years ago

Since I'm a dev as well, my missing extension is the Custom Javascript For Website, a extension that how the name says allow write custom javascript/css for a domain. To me since the beaker is a browser for devs don't looks wrong a native feature like that.

stuartpb commented 2 years ago

I guess what I'd really want is just the ability to extend the browser's UI myself - is it possible to use a Hyperdive to define the UI?

Some of the features it'd be useful to specify in Hypercores (maybe as mounts under My Private Drive):

Another function in proximity to extensions: is there a way to register daemons or Hypercore event listeners in the current API? (something like ServiceWorkers?)

Ygarr commented 2 years ago

I think the browser does not need adblocker, cause there are solutions like hblock. But there extensions without which you simply cannot go online. But it is: LocalCDN or Decentraleyes and umatrix, JS disabler. It would be nice to add them

RangerMauve commented 2 years ago

If I may shamelessly plug my project, Agregore. We support a bunch of p2p protocols like hypercore, IPFS, and BitTorrent, and all of these protocols are available to web extensions via the browser's fetch() API (and images and the such).

A bunch of the internals are actually implemented with extensions, and we bundle UBlock Origin by default.