4 ms·

This is a bit cynical isn't it, when the author is clearly being as transparent as possible about what they need and why, which is due to factors outside their

This is a bit cynical isn't it, when the author is clearly being as transparent as possible about what they need and why, which is due to factors outside their control. Of course you're right in a technical sense. They could do whatever they want later. But still let's celebrate and attitude like this rather than criticizing it.

bee_rider 3y ago
It would be more transparent to be candid about the limitation of what they can provide. It isn’t the developer’s fault that the ecosystem is dumb, but they could just note the limitation.
- tsimionescu 3y ago
  So you're saying they shouldn't add the feature rather than asking for the permission?
  - bee_rider 3y ago
    No, they should just note the issue in a parenthetical aside.
jessriedel 3y ago
Nope. People are being asked to give a bunch of deep access to their system, it's not enough for the author to have pure intensions and explain why they asked. The user should understand the risks, many of which are non-obvious (like the extension being sold).
dotancohen 3y ago
Sounds to me like GP is complaining about Chrome's permission model, not this particular extension.
- Nifty3929 3y ago
  That isn't my interpretation having just reread it, but if that poster comes back to clarify otherwise I'll edit my post accordingly.
shakna 3y ago
It's not cynical - see what happened to ublock. That kind of mess has happened, and will continue to happen, and should be a factor in what you choose to trust.
- gorhill 3y ago
  The extension in the Chrome Web Store (CWS) never changed hands. I just reverse-forked a GitHub repo, which was of no consequences to those who installed the extension from the CWS. I was asked to transfer the CWS entry, I refused. This can't be compared to an extension changing hands or going rogue in the CWS.
- efilife 3y ago
  What happened to ublock? Are you talking about uBlock origin?
  - Denote6737 3y ago
    It was uBlock that was bought by AdBlock. uBlock origin is a different project and wasn't part of the sale. it is not accepting payment for ads.
  - eslaught 3y ago
    The Wiki article has a brief summary of the history, but basically the original author wanted to transfer responsibility for the user-facing maintenance to someone else, who started seeking donations and (I believe) taking payment for "acceptable ads" and the like. https://en.wikipedia.org/wiki/UBlock_Origin#uBlock https://en.wikipedia.org/wiki/UBlock_Origin#uBlock
- josefx 3y ago
  Wasn't the worst that happened with it that the guy who took over uBlock tried to take credit for it and asked for donations? Not like he could get away with anything outright illegal when everyone knew he was running the project.
lowbloodsugar 3y ago
But WHY do they need that permission? They dont need it to implement the paste behavior. Looks super sus to me.
- ambigious7777 3y ago
  The extension needs to re-enable paste, which means it needs to possibly inject some JS into the page.
  - lowbloodsugar 3y ago
    And they need a tab event to do that? Or could it just be done with a button on the toolbar. One doesn't need broad security permissions.
foofie 3y ago
> This is a bit cynical isn't it (...) No, it's called security. Let's put it this way: there have been FLOSS projects whose maintainers intentionally pushed compromised code to unsuspecting end users. See for example the colors attack. What leads you to believe that good intentions are enough?
- bakugo 3y ago
  > Let's put it this way: there have been FLOSS projects whose maintainers intentionally pushed compromised code to unsuspecting end users. See for example the colors attack. Following this logic, we should all stop using any and all software for which we haven't personally inspected the full source code for, since this could happen to any of them.
  - ziddoap 3y ago
    That's the extreme end, sure. A more reasonable take would be to assess your risk tolerance and the possible benefit for each piece of software you install, and then make the best decision for yourself based on that assessment. For some people, that means not running an extension that provides minor quality of life improvements due to the possibility of it turning malicious further down the road. For other people, it means the opposite. Not sure why every security-related conversation devolves into one extreme vs. another extreme. Security must be appropriately balanced against risk tolerance, inconvenience, and a number of individual concerns and preferences.
    - bakugo 3y ago
      If you personally think extensions are too much of a security risk for you, sure, don't use them. But please don't comment "ackshually extensions are insecure and using them is a bad idea" on every post about a browser extension. We already know the risks, it's explained when you install them, we don't need to hear the same lecture every day.
      - ziddoap 3y ago
beacon294 3y ago
No, it's well documented. Popular Chrome plugins, mainly free ones, historically have been sold.
Beldin 3y ago
This has been used as an attack vector in the past: spot reasonably popular plugin; make author an offer; inject whatever tracking/other malwate stuff new owners want (typically after a delay). So now we'd have to trust the author to do thorough vetting of a potential buyer and also not sell if vetting is inconclusive. And this against an adversary aiming to cheat their way past vetting. Might be a cynical take, but it is not one without reason. As a sibling comment points out, this is due to the permission model. This doesn't let the author entirely of the hook though: the permissions model created the situation, the author chose a particular path. The consequences may not have been foreseen by either, but they do exist and affect users.
- tracker1 3y ago
  In this case, you can build and self host on Dev mode... It's a pain but doable.
- bryanrasmussen 3y ago
  >the permissions model created the situation, the author chose a particular path. perhaps the most reasonable or even only possible path if they wanted their plugin to be able to do what they wanted it to do, which was to keep sites and from messing with your copy and paste functionality - in other words to prevent minor maliciousness. on edit: sure, to provide the smoothest behavior, but really if it wasn't smooth people would be irritated and not want to use it. I know if I was implementing for myself I would want it to be smooth. I understand the whole "bad things can be done" perspective, but here for some reason I fall under a "trust but verify" perspective instead.

bee_rider 3y ago

It would be more transparent to be candid about the limitation of what they can provide. It isn’t the developer’s fault that the ecosystem is dumb, but they could just note the limitation.

tsimionescu 3y ago
So you're saying they shouldn't add the feature rather than asking for the permission?
- bee_rider 3y ago
  No, they should just note the issue in a parenthetical aside.

jessriedel 3y ago

Nope. People are being asked to give a bunch of deep access to their system, it's not enough for the author to have pure intensions and explain why they asked. The user should understand the risks, many of which are non-obvious (like the extension being sold).

dotancohen 3y ago

Sounds to me like GP is complaining about Chrome's permission model, not this particular extension.

Nifty3929 3y ago
That isn't my interpretation having just reread it, but if that poster comes back to clarify otherwise I'll edit my post accordingly.

shakna 3y ago

It's not cynical - see what happened to ublock. That kind of mess has happened, and will continue to happen, and should be a factor in what you choose to trust.

gorhill 3y ago
The extension in the Chrome Web Store (CWS) never changed hands. I just reverse-forked a GitHub repo, which was of no consequences to those who installed the extension from the CWS. I was asked to transfer the CWS entry, I refused. This can't be compared to an extension changing hands or going rogue in the CWS.
efilife 3y ago
What happened to ublock? Are you talking about uBlock origin?
- Denote6737 3y ago
  It was uBlock that was bought by AdBlock. uBlock origin is a different project and wasn't part of the sale. it is not accepting payment for ads.
- eslaught 3y ago
  The Wiki article has a brief summary of the history, but basically the original author wanted to transfer responsibility for the user-facing maintenance to someone else, who started seeking donations and (I believe) taking payment for "acceptable ads" and the like. https://en.wikipedia.org/wiki/UBlock_Origin#uBlock https://en.wikipedia.org/wiki/UBlock_Origin#uBlock
josefx 3y ago
Wasn't the worst that happened with it that the guy who took over uBlock tried to take credit for it and asked for donations? Not like he could get away with anything outright illegal when everyone knew he was running the project.

lowbloodsugar 3y ago

But WHY do they need that permission? They dont need it to implement the paste behavior. Looks super sus to me.

ambigious7777 3y ago
The extension needs to re-enable paste, which means it needs to possibly inject some JS into the page.
- lowbloodsugar 3y ago
  And they need a tab event to do that? Or could it just be done with a button on the toolbar. One doesn't need broad security permissions.

foofie 3y ago

> This is a bit cynical isn't it (...) No, it's called security. Let's put it this way: there have been FLOSS projects whose maintainers intentionally pushed compromised code to unsuspecting end users. See for example the colors attack. What leads you to believe that good intentions are enough?

bakugo 3y ago
> Let's put it this way: there have been FLOSS projects whose maintainers intentionally pushed compromised code to unsuspecting end users. See for example the colors attack. Following this logic, we should all stop using any and all software for which we haven't personally inspected the full source code for, since this could happen to any of them.
- ziddoap 3y ago
  That's the extreme end, sure. A more reasonable take would be to assess your risk tolerance and the possible benefit for each piece of software you install, and then make the best decision for yourself based on that assessment. For some people, that means not running an extension that provides minor quality of life improvements due to the possibility of it turning malicious further down the road. For other people, it means the opposite. Not sure why every security-related conversation devolves into one extreme vs. another extreme. Security must be appropriately balanced against risk tolerance, inconvenience, and a number of individual concerns and preferences.
  - bakugo 3y ago
    If you personally think extensions are too much of a security risk for you, sure, don't use them. But please don't comment "ackshually extensions are insecure and using them is a bad idea" on every post about a browser extension. We already know the risks, it's explained when you install them, we don't need to hear the same lecture every day.
    - ziddoap 3y ago

beacon294 3y ago

No, it's well documented. Popular Chrome plugins, mainly free ones, historically have been sold.

Beldin 3y ago

This has been used as an attack vector in the past: spot reasonably popular plugin; make author an offer; inject whatever tracking/other malwate stuff new owners want (typically after a delay). So now we'd have to trust the author to do thorough vetting of a potential buyer and also not sell if vetting is inconclusive. And this against an adversary aiming to cheat their way past vetting. Might be a cynical take, but it is not one without reason. As a sibling comment points out, this is due to the permission model. This doesn't let the author entirely of the hook though: the permissions model created the situation, the author chose a particular path. The consequences may not have been foreseen by either, but they do exist and affect users.

tracker1 3y ago
In this case, you can build and self host on Dev mode... It's a pain but doable.
bryanrasmussen 3y ago
>the permissions model created the situation, the author chose a particular path. perhaps the most reasonable or even only possible path if they wanted their plugin to be able to do what they wanted it to do, which was to keep sites and from messing with your copy and paste functionality - in other words to prevent minor maliciousness. on edit: sure, to provide the smoothest behavior, but really if it wasn't smooth people would be irritated and not want to use it. I know if I was implementing for myself I would want it to be smooth. I understand the whole "bad things can be done" perspective, but here for some reason I fall under a "trust but verify" perspective instead.