7 ms·

I'm one of the authors of a browser automation framework called remote-browser that's built on top of the Web Extensions API [1]. The meaning behind the name is

by foob 5y ago

I'm one of the authors of a browser automation framework called remote-browser that's built on top of the Web Extensions API [1]. The meaning behind the name is that you have access to a Web Extension API browser object in the client environment that gives you remote access to the full API. That offers enough power to do complex browser automation tasks along the same lines of what you can do with Selenium or Puppeteer, but simply using vanilla JavaScript and the Web Extensions API instead of tons of browser-specific implementation code and a custom automation API. If Firefox follows Chrome's lead on removing executeScript, then it will effectively kill the remote-browser project. I find it very unfortunate that the capabilities of browser extensions are being crippled. I understand that there are significant security issues with browser extensions, but the same general purpose APIs that allow abuse simultaneously allow really wonderful and powerful things to be built. As a developer who loves extending and personalizing their browser, it's simply depressing to see that go. [1] - https://github.com/intoli/remote-browser https://github.com/intoli/remote-browser

ROARosen 5y ago
> I understand that there are significant security issues with browser extensions Sure, there are significant security issues. Since when is that a reason to disable a user-originated threat vector? As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not? Even if this line of argument cannot be said for every purpose - and I understand there is a potential for abuse and misinformation about misrepresenting any specific extension - but for instance say Tampermonkey, which the user needs to first download from the webstore then the user needs to also download the script, can't there be sufficient warning that what the user is doing is potentially harmful? Or a requirement from the webstore that Tampermonkey somehow also alert users before loading any remote scripts? If a user decides to downright download malware we let them (Given, Chrome would block it but you can override that manually) why wouldn't the user be allowed to override these risks (i.e. you can enable it only in development mode etc. with a requirement that such extensions provide sufficient warnings etc.)
- xyzzy_plugh 5y ago
  > As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not? If you've been following the Epic v. Apple case, you'd know some folks like Tim Cook strongly believe the answer is no, or in his words "they shouldn't have to [decide]." The freedom-less future sure seems pretty bleak.
  - simonh 5y ago
    Well I’m a user and I don’t want to have to make that choice. For example I’m not a big fan of Facebook, but I do use it occasionally to keep in contact with some friends. Suppose Facebook decided to move to a different third party store on iOS, maybe their own store, so they don’t have to list their data access and sharing policies, don’t have to go through app store review, etc. Doing that forces me to choose between rigorous app review and disclosure, and using the Facebook app. I don’t want to be put in that position. One of the reasons I use an iPhone is because of that.
    - shock 5y ago
      Regardless of whether you have the responsibility to make that choice or not, you are still responsible for dealing with the consequences of whatever choice has been made for you. How is that any better that being responsible for making the choice in the first place?
    - zajd 5y ago
      "Rigorous app review" > https://www.theverge.com/2021/4/21/22385859/apple-app-store-scams-fraud-review-enforcement-top-grossing-kosta-eleftheriou https://www.theverge.com/2021/4/21/22385859/apple-app-store-... Bad news buddy, you're already in the boat you don't want to be in.
  - unknown_error 5y ago
    As both a developer and a user, a lot of the software "freedoms" we have are superfluous, duplicative, and inefficient. As technology becomes more and more commoditized and 50,000 vendors all sell roughly the same thing, decision fatigue sets in. The walled gardens provide value not because they remove freedom but because they give you back something most people value more: time. We don't all have time to sit around evaluating 1,000 similar packages, compiling and debugging them from scratch, just to get a simple app or game working. The bleeding edge will keep on bleeding, but for the rest of us, good enough is good enough. It doesn't have to be perfect, it just has to work well enough and not add to our already-overwhelmed mental loads.
meibo 5y ago
What is being crippled here? The API is being moved to another objects and restructured in a way that's not as haphazard for actual extension development and distribution. If this doesn't work for your specific use case, write a wrapper object - your point is that the API was stable with V2, but it will still be with V3 and you should be able to rely on that. Am I missing something?
- comex 5y ago
  Read the post more closely. It’s not just an API reshuffle. Chrome is restricting the ability for extensions to run JavaScript code that is dynamically generated or loaded, limiting them (in many cases) to static scripts embedded in the extension itself.
  - martinsbalodis 5y ago
    They are only disallowing code execution within content script sandbox. You can still create a <script> tag with custom code. The script will be run in page sandbox. The main difference is that it won't be able to access chrome.* APIs but it could be affected by CSP. I doubt that tampermonkey executes custom scripts within content script sandbox since a script could take over the extension itself. They should be fine. Please note that as an extension developer I receive at least once a month a cash offer to inject scripts that track users.
- foob 5y ago
  What is being crippled here? The ability to execute arbitrary JavaScript in content scripts at runtime. Remote-browser works by making it very easy to run code in content and background script contexts from a remote client. Typical browser automation tasks like filling out an input, clicking a button, or extracting the HTML of an element are accomplished by marshaling code and results between the browser and the client. your point is that the API was stable with V2 My point isn't that the API was stable, it's that Google is moving towards removing key features from the API because they consider them to be too powerful. Blocking webRequest and executeScript are two notable examples.
CyberRabbi 5y ago
I think you’re using the wrong API. For remote automation you should be using the chrome devtools protocol[1]. It is meant for your purposes and gives you full script injection functionality and dom access. [1]: https://chromedevtools.github.io/devtools-protocol/ https://chromedevtools.github.io/devtools-protocol/
- Vinnl 5y ago
  That's what Puppeteer and Playwright do, and I think that's what they wanted to avoid given > instead of tons of browser-specific implementation code and a custom automation API.
mech422 5y ago
I get annoyed with the 'think of the (metaphorical) children' school of safety. If you want to do something to improve people's safety awareness - make actual browser dialogs and chrome distinctive and unforgable (maybe a special window chrome or something). Half the time now, I just close tabs because I'm not sure that lil 'x'(close) on the ad that popped up isn't part some malware. When its too easy to duplicate 'official' looking stuff, people become numb to seeing it all the time.
- teddyh 5y ago
  > maybe a special window chrome or something A.k.a. the “line of death”: https://www.theregister.com/2017/01/19/browser_line_of_death/ https://www.theregister.com/2017/01/19/browser_line_of_death...
  - mech422 5y ago
    Wow...that was ... scary. At least now I know its not just me having these issues. Thanks!
bryanrasmussen 5y ago
I have some personal projects I might finally get a chance to work on a bit and they were all intended to use remote-browser, now you have me worried. however I see no reason why firefox should follow chrome on this? Also my natural paranoia in regards to the motivations of Google make me think maybe executeScript is too powerful and allows the extension makers to do things that are not malignant, but just against the corporate interests of Google.
- foob 5y ago
  I hope you're right about Firefox. I think their hand is forced in terms of supporting any API additions that Google makes because of Chrome's dominance among extension developers, but they can choose to maintain support for the manifest v2 features that are getting removed. I would love to hear more about your personal project ideas that involve remote-browser. My contact info is in my profile, feel free to reach out.

by foob 5y ago

ROARosen 5y ago

> I understand that there are significant security issues with browser extensions Sure, there are significant security issues. Since when is that a reason to disable a user-originated threat vector? As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not? Even if this line of argument cannot be said for every purpose - and I understand there is a potential for abuse and misinformation about misrepresenting any specific extension - but for instance say Tampermonkey, which the user needs to first download from the webstore then the user needs to also download the script, can't there be sufficient warning that what the user is doing is potentially harmful? Or a requirement from the webstore that Tampermonkey somehow also alert users before loading any remote scripts? If a user decides to downright download malware we let them (Given, Chrome would block it but you can override that manually) why wouldn't the user be allowed to override these risks (i.e. you can enable it only in development mode etc. with a requirement that such extensions provide sufficient warnings etc.)

xyzzy_plugh 5y ago
> As long as the user in question is informed and alerted to the potential security risks shouldn't it be within the user's purview to decide what to allow and what not? If you've been following the Epic v. Apple case, you'd know some folks like Tim Cook strongly believe the answer is no, or in his words "they shouldn't have to [decide]." The freedom-less future sure seems pretty bleak.
- simonh 5y ago
  Well I’m a user and I don’t want to have to make that choice. For example I’m not a big fan of Facebook, but I do use it occasionally to keep in contact with some friends. Suppose Facebook decided to move to a different third party store on iOS, maybe their own store, so they don’t have to list their data access and sharing policies, don’t have to go through app store review, etc. Doing that forces me to choose between rigorous app review and disclosure, and using the Facebook app. I don’t want to be put in that position. One of the reasons I use an iPhone is because of that.
  - shock 5y ago
    Regardless of whether you have the responsibility to make that choice or not, you are still responsible for dealing with the consequences of whatever choice has been made for you. How is that any better that being responsible for making the choice in the first place?
  - zajd 5y ago
    "Rigorous app review" > https://www.theverge.com/2021/4/21/22385859/apple-app-store-scams-fraud-review-enforcement-top-grossing-kosta-eleftheriou https://www.theverge.com/2021/4/21/22385859/apple-app-store-... Bad news buddy, you're already in the boat you don't want to be in.
- unknown_error 5y ago
  As both a developer and a user, a lot of the software "freedoms" we have are superfluous, duplicative, and inefficient. As technology becomes more and more commoditized and 50,000 vendors all sell roughly the same thing, decision fatigue sets in. The walled gardens provide value not because they remove freedom but because they give you back something most people value more: time. We don't all have time to sit around evaluating 1,000 similar packages, compiling and debugging them from scratch, just to get a simple app or game working. The bleeding edge will keep on bleeding, but for the rest of us, good enough is good enough. It doesn't have to be perfect, it just has to work well enough and not add to our already-overwhelmed mental loads.

meibo 5y ago

What is being crippled here? The API is being moved to another objects and restructured in a way that's not as haphazard for actual extension development and distribution. If this doesn't work for your specific use case, write a wrapper object - your point is that the API was stable with V2, but it will still be with V3 and you should be able to rely on that. Am I missing something?

comex 5y ago
Read the post more closely. It’s not just an API reshuffle. Chrome is restricting the ability for extensions to run JavaScript code that is dynamically generated or loaded, limiting them (in many cases) to static scripts embedded in the extension itself.
- martinsbalodis 5y ago
  They are only disallowing code execution within content script sandbox. You can still create a <script> tag with custom code. The script will be run in page sandbox. The main difference is that it won't be able to access chrome.* APIs but it could be affected by CSP. I doubt that tampermonkey executes custom scripts within content script sandbox since a script could take over the extension itself. They should be fine. Please note that as an extension developer I receive at least once a month a cash offer to inject scripts that track users.
foob 5y ago
What is being crippled here? The ability to execute arbitrary JavaScript in content scripts at runtime. Remote-browser works by making it very easy to run code in content and background script contexts from a remote client. Typical browser automation tasks like filling out an input, clicking a button, or extracting the HTML of an element are accomplished by marshaling code and results between the browser and the client. your point is that the API was stable with V2 My point isn't that the API was stable, it's that Google is moving towards removing key features from the API because they consider them to be too powerful. Blocking webRequest and executeScript are two notable examples.

CyberRabbi 5y ago

I think you’re using the wrong API. For remote automation you should be using the chrome devtools protocol[1]. It is meant for your purposes and gives you full script injection functionality and dom access. [1]: https://chromedevtools.github.io/devtools-protocol/ https://chromedevtools.github.io/devtools-protocol/

Vinnl 5y ago
That's what Puppeteer and Playwright do, and I think that's what they wanted to avoid given > instead of tons of browser-specific implementation code and a custom automation API.

mech422 5y ago

I get annoyed with the 'think of the (metaphorical) children' school of safety. If you want to do something to improve people's safety awareness - make actual browser dialogs and chrome distinctive and unforgable (maybe a special window chrome or something). Half the time now, I just close tabs because I'm not sure that lil 'x'(close) on the ad that popped up isn't part some malware. When its too easy to duplicate 'official' looking stuff, people become numb to seeing it all the time.

teddyh 5y ago
> maybe a special window chrome or something A.k.a. the “line of death”: https://www.theregister.com/2017/01/19/browser_line_of_death/ https://www.theregister.com/2017/01/19/browser_line_of_death...
- mech422 5y ago
  Wow...that was ... scary. At least now I know its not just me having these issues. Thanks!

bryanrasmussen 5y ago

I have some personal projects I might finally get a chance to work on a bit and they were all intended to use remote-browser, now you have me worried. however I see no reason why firefox should follow chrome on this? Also my natural paranoia in regards to the motivations of Google make me think maybe executeScript is too powerful and allows the extension makers to do things that are not malignant, but just against the corporate interests of Google.

foob 5y ago
I hope you're right about Firefox. I think their hand is forced in terms of supporting any API additions that Google makes because of Chrome's dominance among extension developers, but they can choose to maintain support for the manifest v2 features that are getting removed. I would love to hear more about your personal project ideas that involve remote-browser. My contact info is in my profile, feel free to reach out.