On Web Extensions shortcomings and their impact on add-on security(palant.de)
palant.de
On Web Extensions shortcomings and their impact on add-on security
https://palant.de/2017/11/11/on-web-extensions-shortcomings-and-their-impact-on-add-on-security
29 comments
I always thought it was bizarre that WebExtensions had no UI framework. Injecting stuff into a website seems like a poor solution
An extension overlay API would have saved me so much pain when building Saka (saka.io). There are two options for injecting UI today:
1. Inject UI directly into the document
2. Inject an iframe containing the UI into the document
Both rely on manipulating the document, which can be used to fingerprint users. Most developers opt for 1 because it requires no setup and lets the content script synchronously access the UI. 2 is needed when the injected UI containing sensitive information.
I'd like an extension overlay API that lets you inject: 1. UI local to the tab 2. UI that persists across all tabs
In a brief #webextensions IRC discussion, I was told an overlay API isn't viable for a number of reasons, one of which is multiple extensions may conflict.
1. Inject UI directly into the document
2. Inject an iframe containing the UI into the document
Both rely on manipulating the document, which can be used to fingerprint users. Most developers opt for 1 because it requires no setup and lets the content script synchronously access the UI. 2 is needed when the injected UI containing sensitive information.
I'd like an extension overlay API that lets you inject: 1. UI local to the tab 2. UI that persists across all tabs
In a brief #webextensions IRC discussion, I was told an overlay API isn't viable for a number of reasons, one of which is multiple extensions may conflict.
Did they tell you how the extensions may conflict? I don't understand what it means. Couldn't it work like e.g. context menu does already for extension icon?
What happens when two extensions try to place a widget in the same location? Chaos. Not that the status quo is any better.
Interestingly, Firefox's sidebar API only allows a single sidebar to be shown.
Interestingly, Firefox's sidebar API only allows a single sidebar to be shown.
I still don't get it. What problem they're trying to avoid?
It's exactly the same if two extensions would currently try to manipulate the page by adding a frame (or, worse, a <div> with non-isolated UI) to the same location.
The only difference is, with out-of-page widgets (e.g. overlay regions or popouts), they won't be visible in the page's DOM.
It's exactly the same if two extensions would currently try to manipulate the page by adding a frame (or, worse, a <div> with non-isolated UI) to the same location.
The only difference is, with out-of-page widgets (e.g. overlay regions or popouts), they won't be visible in the page's DOM.
My understanding is that if they do implement an API, they want it to be better than the status quo, not the same.
That's all these extensions are. Injecting stuff into websites, usually all of them.
I needed a Chrome extension after they inexplicably broke backspace navigating backwards (it literally has the same icon as the backwards UI button). That extension needs to inject a script on every. single. website.
It's like Google is spending millions upon dollars building convoluted sandboxing security features, and there is a place for that in protecting us from code execution. But then everyone is pushing for "apps on the web" and here we are with random extensions that can do everything. And they do: lots of them make money through selling your browsing history.
I needed a Chrome extension after they inexplicably broke backspace navigating backwards (it literally has the same icon as the backwards UI button). That extension needs to inject a script on every. single. website.
It's like Google is spending millions upon dollars building convoluted sandboxing security features, and there is a place for that in protecting us from code execution. But then everyone is pushing for "apps on the web" and here we are with random extensions that can do everything. And they do: lots of them make money through selling your browsing history.
> they inexplicably broke backspace navigating backwards
Hallelujah, praise the lord! He is righteous and he is Good.
Finally. I cannot count the number of times I accidentally hit tab in a form text input, backspace, and lose the entire form. Of course it’s built in JS so state isn’t saved by browser on going forward. Because why use standards? It’s 2017, ain’t nobody got time for functionality.
It got so bad I now automatically open a text editor to write the text in, first.
This was a bug bear of epic proportions. Good riddance.
Hallelujah, praise the lord! He is righteous and he is Good.
Finally. I cannot count the number of times I accidentally hit tab in a form text input, backspace, and lose the entire form. Of course it’s built in JS so state isn’t saved by browser on going forward. Because why use standards? It’s 2017, ain’t nobody got time for functionality.
It got so bad I now automatically open a text editor to write the text in, first.
This was a bug bear of epic proportions. Good riddance.
Meh, backspace-for-back should not fire when a input element of any type (i.e. including anchors) have an active focus. Also, "forward" should restore this state but since it's in JS perhaps the aim of your complaints is misplaced and should direct to the site owner.
It should at least be opt in (not sure where the setting is in Chrome).
It should at least be opt in (not sure where the setting is in Chrome).
[deleted]
That was the standard navigation method of every webbrowser for decades, not a bug.
As far as I know, using backspace to go back was something from Internet Explorer, which other browsers copied as a concession to users used to it, but only on Windows. I've used Firefox for over a decade, and backspace never went to the previous page for me, even on a new install, so "every webbrowser for decades" is a stretch.
Firefox on Linux has supported it for ages, too. I’ve used it frequently, at least.
Just because something is and has been standard for a long time, it doesn't make it good UX.
It sucks that it's gone - it took me months to retrain my muscle memory to stop using backspace - but I've definitely accidentally navigated back from a form before.
I've adjusted. It's a hard decision but imo the right one. Future generations shouldn't have to deal with this.
To anyone reading who needs a keyboard-based substitute: Alt+Left Arrow.
I've adjusted. It's a hard decision but imo the right one. Future generations shouldn't have to deal with this.
To anyone reading who needs a keyboard-based substitute: Alt+Left Arrow.
[Alt]+[←] requires two hands, though: One to press the [Alt] on the far left of the keyboard, one to press [←] on the far right of the keyboard.
That’s horrible.
That’s horrible.
That's weird, because I press it all the time with one hand. I don't even reliably use the same hand. Does your keyboard not have an Alt key to the right of the space-bar?
On international keyboards, there is no right alt key, but instead at that place is [AltGr], which triggers both [Alt] and [Ctrl].
[AltGr]+[M] for example gives μ, [AltGr]+[E] gives € and [AltGr]+[Q] gives [@]. Obviously, [AltGr]+[←] doesn't work.
It's one more of those shortcuts that make it obvious that whoever made the decision only ever used a US Standard keyboard, and never even considered international users. The only decisions even worse are ever using ` (it's a 4 key combo on some international keyboards, and not at all existing on others), or ~ \ [ ] { } ( ) ; : (all of these are combinations of usually two or three keys on most international keyboards).
[AltGr]+[M] for example gives μ, [AltGr]+[E] gives € and [AltGr]+[Q] gives [@]. Obviously, [AltGr]+[←] doesn't work.
It's one more of those shortcuts that make it obvious that whoever made the decision only ever used a US Standard keyboard, and never even considered international users. The only decisions even worse are ever using ` (it's a 4 key combo on some international keyboards, and not at all existing on others), or ~ \ [ ] { } ( ) ; : (all of these are combinations of usually two or three keys on most international keyboards).
I typically use a vim-like set of keybinds when possible, so for me it's something like shift-H or g,h.
There is a bit of separate ui, both for the config page and the div (popup panel) that pops when you click the extension button.
What were you looking for instead?
What were you looking for instead?
the problem with the Pop-Up panel is that you cannot open it programmatically
[deleted]
Secure access to the clipboard is probably going to require a permission prompt. Otherwise it seems too risky.
Already out of the bag. You can manipulate the clipboard now from extensions.
And behind a permission: see "Clipboard access" in https://developer.mozilla.org/en-US/Add-ons/WebExtensions/ma...
The only shortcoming is the user. Only install ad ons that you know and understand. And only from the official project source.
Or you can (correctly) assume users are a danger to themselves and coddle them. The Google Chrome/Apple/Microsoft philosophy.
Or you can (correctly) assume users are a danger to themselves and coddle them. The Google Chrome/Apple/Microsoft philosophy.
You can't just blame the user when bad actors actively seek to purchase and re-purpose browser extensions, open source projects, downloaded software etc into malware. It will be our turn when they figure out how to compromise NPM etc modules profitably.
History has shown us that users are overwhelmingly a danger to themselves when it comes to this sort of thing. Pretending otherwise is not a good strategy.
Oh I know. People are why we can't have nice things. Like add ons.
Already you can't install the latest versions unless Mozilla approves them.
I just prefer freedom, including the freedom to make mistakes.
Already you can't install the latest versions unless Mozilla approves them.
I just prefer freedom, including the freedom to make mistakes.