Support for Bookmarklets

[pfrazee]

By request (https://github.com/pfrazee/beaker/pull/92#issuecomment-246541404). This will need three updates:

1. Ability to add new bookmarks manually
2. A bookmarks bar under the url
3. Ability to add/remove bookmarks to the bar

[millette]

Would these bookmarklets have access to the full web APIs? Would it still depend on the location, http:// or dat:// ?

[pfrazee]

They'd execute within the current page's context, which means it would depend on the location. I'm a little torn about adding bookmarklets. We have plans for better forms of contextual actions.

[millette]

I see. Even if you add a

better forms of contextual actions

bookmarklets are still out there. I have one to generate passwords, for instance. I think there could still be a use for them.

BTW, you've thanked me many times already for my issue comments, while I don't think I thanked you once yet for Beaker. Consider it done! :-)

[pfrazee]

Thanks :)

bookmarklets are still out there. I have one to generate passwords, for instance. I think there could still be a use for them.

The key problem with bookmarklets is, they're run as injections into the current page. Once we tighten up the Content-Security Policies in dat:// sites, that kind of injection will be blocked. HTTP/S sites may also block them with their own CSPs. So, I think we have to alter the model.

The key question is, do bookmarklets need direct access to the page to do useful work? If the answer can be "no," then we'll have a much easier time moving forward.

[millette]

I'm really not up-to-date with CSPs, but I trust your judgement.

I'm going a bit off-topic, I hope you'll indulge me.

Another bookmarklet I sometimes use is the following (the details aren't important, only that it modifies the page):

(function() {
  var r, news = document.querySelectorAll(
      '.blended-wrapper.esc-wrapper'),
    langs = {
      en: 'ago',
      fr: 'il y a',
      'fr-CA': 'il y a',
      es: 'hace'
    };
  if ('undefined' === typeof ___jsl ||
    'undefined' === typeof ___jsl.cfg ||
    'undefined' === typeof ___jsl.cfg
    .lang || 'undefined' === typeof langs[
      ___jsl.cfg.lang]) {
    console.log("Langage inconnu.");
    return;
  }
  for (r = 0; r < news.length; r) {
    if (-1 === news[r].querySelector(
        '.al-attribution-timestamp').innerHTML
      .indexOf(langs[___jsl.cfg.lang])
    ) {
      news[r].style.display = 'none';
    }
  }
}());

I use it on Google News to filter out items older than a day. You're saying Google could update its CSP for that site which would prevent my bookmarklet from running, is that it? Of course, they could change anything in their source that could bust the bookmarklet, but that's a whole other matter.

It happens quite often I'll write a bookmarklet to modify a page - but this habit of mine could be taken away from me, in general?

[pfrazee]

I'm going a bit off-topic, I hope you'll indulge me.

Not at all, this is helpful

I use it on Google News to filter out items older than a day. You're saying Google could update its CSP for that site which would prevent my bookmarklet from running, is that it?

Correct -- and it's usually a positive that they do, because it protects against attacks by injection.

It happens quite often I'll write a bookmarklet to modify a page - but this habit of mine could be taken away from me, in general?

That's a possibility, yes.

People have raised the same concerns you have with FF and Chrome. It may be possible that CSPs can be circumvented to support bookmarklets. I dislike taking control away from users, so unless there's a strong security case against that, I'd be in favor of keeping bookmarklets.

---

Looking back at the big picture:

When it comes to page modification, the concept we're aiming for is "Fork to modify."

We're also going to implement 1) a subset of the WebExtensions API and 2) a revived form of WebIntents.

We're hoping these can cover enough use-cases that injection won't be necessary anymore.

[millette]

Great, thanks for all the feedback and references.

[Gozala]

The key problem with bookmarklets is, they're run as injections into the current page. Once we tighten up the Content-Security Policies in dat:// sites, that kind of injection will be blocked. HTTP/S sites may also block them with their own CSPs. So, I think we have to alter the model.

Please note that not all bookmarklets need to inject third party resources into the page, most do because that provides simple update mechanism, that is they publish update to the script that bookmarklet injects on their servers.

You could have bookmarklet that has all the logic inline & have more evolved update mechanism that would talk to corresponding server and if update found prompt user in some way to suggest update.

So I'd still encourage to add support for bookmarklets.

[trentlarson]

I see this has been "added" to 1.0.0-prerelease.8
Does that mean bookmarklets will be enabled in that version (if nothing changes)? (I don't see any PRs or related code, so I'm not sure what it means by "added" back on prerelease.6)

[aadilayub]

Is this still on the roadmap? Would be cool to be able to use http://hypothes.is in Beaker (even if just with HTTP/S websites)