I'm looking at this from the perspective of the plugin developer not the user of the browser, so I'm interested in what developers think is the ideal interface for plugins to a browser. For example: Plugins can reorder, create and destroy Tabs, Plugins can draw behind and in front of Browser pages etc.
I'm particularly concerned about the security aspects
A web browser should have a firebug plug inn which help the developers.Concerned about security browser should block Phishing.
The major thing that I look for right away is how easy it is to open a preference pane, new windows, and the security preference variables.
I also like the ability to iterate through tabs, searching through various aspects such as page currently displayed within each of those tabs.
Related
I asked this question a little over a week ago on the Atom forums (link below), and didn't receive a response, so I am reposting it here in the hopes that someone may be able to provide insight on my problem.
Recently, I have taken up an open source project which uses Electron as it’s front-end. This project has two requirements: it must be cross-platform, and it must have an embedded web browser (which should be able to browse the web and render content like a typical browser). Considering the rather large footprint Electron has already netted my application, it seems like a bad idea to attempt to use another embedded web framework alongside it. So, in the interest of simplifying my project and retaining the UI built on top of Electron, I am looking into using Electron itself as the web browser. Here’s where I’ve come into a problem.
In a security page for Electron’s documentation, it is explicitly stated that,
it is important to understand … Electron is not a web browser
This quote comes within the context that Electron–or rather the code running on top of it–carries the unique ability to interact with the user’s operating system, unlike typical web applications. The page goes on to say,
displaying arbitrary content from untrusted sources poses a severe security risk that Electron is not intended to handle
At this point, I was tempted to give up on the idea of using Electron as an inbuilt browser, but further down on that same page, you can find another very interesting tidbit:
To display remote content, use the <webview> tag or BrowserView , [and] make sure to disable the nodeIntegration and enable contextIsolation
Link: https://electronjs.org/docs/tutorial/security#isolation-for-untrusted-content
First, in regard to using webviews, Electron’s own documentation recommends outright avoiding them:
Electron’s webview tag is based on Chromium’s webview , which is undergoing dramatic architectural changes. This impacts the stability of webviews , including rendering, navigation, and event routing. We currently recommend to not use the webview tag and to consider alternatives, like iframe , Electron’s BrowserView , or an architecture that avoids embedded content altogether.
Link: https://electronjs.org/docs/api/webview-tag
Seeing as though I cannot avoid embedded content, I opted to look into using a BrowserView, but what I found was not very motivating either. The advice, as it stands, is to do two things:
disable nodeIntegration
enable contextIsolation
After looking at the security and best-practices page, I will also append the following steps:
deny session permission requests from remote content (webcam, microphone, location, etc.)
catch webview elements in creation and strip default privileges
disable the creation of new windows
disable the remote module
That is a fair amount of steps to undergo in securing external content. Not to mention, there were several additional warnings scattered through the best practices page such as the following:
(On verifying webview options before creation)
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
Link: https://electronjs.org/docs/tutorial/security#11-verify-webview-options-before-creation
(On disabling the remote module)
However, if your app can run untrusted content and even if you sandbox your renderer processes accordingly, the remote module makes it easy for malicious code to escape the sandbox and have access to system resources via the higher privileges of the main process.
Link: https://electronjs.org/docs/tutorial/security#15-disable-the-remote-module
Not to mention, upon navigation to the BrowserView page, the whole class is listed as experimental.
This all isn’t even to mention the added attack surface created by Electron, such as a vulnerability in the webview component just last year: CVE-2018-1000136
Now, taking into account all of the above, numerous developers have still opted to create web browsers that routinely consume external and uncontrolled content using Electron.
Browser’s using Electron (linked directly from Electron’s website):
https://electronjs.org/apps/wexond
https://electronjs.org/apps/dot
https://electronjs.org/apps/beaker-browser
To me, it seems irresponsible to submit users to the above security implications as a trade-off for convenience.
That being said, my question is: can you safely, to the point at which you could ensure the integrity of your users, implement web browsing capabilities for uncontrolled content using Electron?
Thank you for your time.
Link to the original post:
https://discuss.atom.io/t/security-implications-in-electron-as-a-web-browser/70653
Some ideas that don't fit into a comment box:
[the project] must have an embedded web browser
So I presume then that this project isn't just a web browser. There's other content there that may have access to Node, but you just want the embedded-web-browser portion of it to be sandboxed appropriately, right?
Regarding the comments about <webview>, yes, it is considered unstable and Electron recommends using a BrowserView instead. I don't think that the fact that it's marked as "experimental" should necessarily deter you from using it (especially considering that the Electron team is recommending it [though maybe as the best of two evils]).
Experimental doesn't imply it's unstable. It can just mean that the Electron team is experimenting with this approach, but this approach may change in the future (at which point I would expect Electron to provide a transition path forward). Though this is one possible interpretation and ultimately Electron would have to comment on this.
The advice... is to do two things:
disable nodeIntegration
enable contextIsolation
I would also make use of the sandbox option inherited from BrowserWindows. BrowserView's docs on the constructor options say:
webPreferences Object (optional) - See BrowserWindow.
which tells me that BrowserView accepts the same options as BrowserWindow.
You would set it up like so:
new BrowserView({ webPreferences: {
sandbox: true,
nodeIntegration: false,
contextIsolation: true,
preload: "./pathToPreloadScript.js"
}});
See more information about this approach here. The preload script is what would expose some Node IPC APIs to the sandboxed content you're loading. Note the Status section at the bottom, which says:
Please use the sandbox option with care, as it is still an experimental feature. We are still not aware of the security implications of exposing some Electron renderer APIs to the preload script
If the content you're loading in the BrowserView never needs to communicate back to the application, then you don't need a preload script at all and can just sandbox the BrowserView.
After looking at the security and best-practices page, I will also append the following steps:
deny session permission requests from remote content (webcam, microphone, location, etc.)
catch webview elements in creation and strip default privileges
disable the creation of new windows
disable the remote module
Sure, those sound reasonable. Note that if your embedded browser needs to be able to open new windows (via window.open or <a target="_blank" />) then you'd have to allow popups.
That is a fair amount of steps to undergo in securing external content.
Sure, but is your main concern with the security of the app, or with how much work it takes to make it secure? Browser developers need to consider similar things to ensure webpages can't get access to the OS. It's just part of the game.
Again, this list merely minimizes the risk, it does not remove it. If your goal is to display a website, a browser will be a more secure option.
This is just saying that if all you're trying to do is display a website, then just use a browser since that's what they're there for.
If you need to do other things, well then you can't use a browser, so you'll have to make your own app, making sure it's reasonably secure.
I think that if you follow what's recommended in the Security document and keep up to date with new Electron releases, then you're doing the best you can do.
As for whether that's good enough, I can't say. It depends on what you're developing and what you're trying to protect against.
However, my thoughts can't substitute the more expert opinions of those on the Electron team. This question could certainly use some guidance from them.
I want to build a task-specific web browser. For example, when the user uses that browser, the program should give options like these:
What is your interest today? Please select from the following:
computer science
data science
web development
psychology
biology
social media
etc.
After the user selects their interest, the browser should allow the user to search or study only those selected content types, so the user cannot get diverted from their task. The purpose of this browser is to avoid time-wasting. Because whenever someone tries to study or do some professional work, they get diverted by opening social media tabs and movies.
Which programming language will be suitable for making this browser?
You could do this by making a custom version of an existing browser, as guest271314 suggested, but that would require far more effort than necessary. All you need to make is a browser extension, such as a Firefox Add-on or a Chrome Extension. Browser extensions are usually written with JavaScript, HTML, and CSS. Each browser needs to have an extension made individually, but you can usually share a lot of the code between them. Read the linked documentation for help creating an extension for each browser.
There are already existing browser extensions like you describe that prevent you from visiting sites that you put on a list ahead of time, such as StayFocusd and WasteNoTime. Maybe you just want to use one of those extensions instead of writing a new one.
I know that Apple products like the iPad or the iPhone have trouble with flash apps.
What web development tools should I use in order to avoid compatibility issues when creating a website? My only constraint is that the languages must provide for interactivity and animation - such as in jQuery.
HTML, CSS, and PHP are a few that I can think of that will behave on 99% of all internet enabled devices.
What tools & languages are available to use when creating a website intended to be viewed on any device's internet "explorer"?
Should I just stick to HTML, CSS, & PHP? I want a certain level of interactivity so that, for example, a user can hover over images and have pop-ups containing data to appear... or when an object is clicked, an action can happen without a page reload.
Can someone point me in the right direction and help me develop a list of languages that are all-device friendly?
I am familiar with programming in several web-focused languages, I'm just wondering which ones to stay away from. Certain ones will limit the devices that can view the site and besides that constraint, the site needs to be interactive and animated.
HTML, CSS, PHP, JQUERY are truly your best bet for developing for a wide range of devices. If the scope of devices is the main goal I would stay away from using HTML5 and CSS3. You still may run into problems using much jquery with IE7 below. Mobile browsers on the other hand are much more advanced or up to date with standards then desktop browsers. I would suggest creating two versions of your application. One dedicated to running on mobile devices and one for desktop browsers. It is a shame apple wouldn't support flash applications. If all you need is hoovers for interaction you won't even need jquery / but for the other it will be useful.
The "Web" is a name for the concept of having interlinked documents accessible over the internet. Therefore, to have a website you really only need a document able to link to other documents, namely HTML.
HTML is not really a programming language or a tool though, it is a document format.
If you want to make a website you need use HTML to Markup what you're writing. Then you use CSS to format different sections of the document you marked up.
PHP though, is completely separate from this, PHP is for creating dynamic HTML, or any document on the server side.
If you want to achieve a flash-effect on a site you use Javascript to modify the page content (HTML) and appearance (CSS).
If you need to learn HTML/CSS I would highly recommend http://htmldog.com/
As per the question, HTML CSS and Javascript are pretty much the only mobile-browser compatible method for website content as they don't need plugins.
What exactly are you trying to do?
Is there any good reason why I can't use two of them together?
browser_action
page_action
app
I can't think why single extension can't use browser and page specific actions together. Why should I have to write single extension for each action ...
For a browser that boasts about its simplicity I believe that is the clearest explanation. To prevent clutter.
Packaged Apps is the easiest to explain as they are basically an alternative to Hosted Apps for developers that don't wish to host a service or wish to make their app fully integrated in to Chrome and/or work offline. However, since packaged apps are bundled as extensions this prevents them from adding anything to the browser's chrome since hosted apps don't have this ability.
Regarding the action choice, I can only imagine this restriction is to help prevent extensions from overcrowding the address bar and the toolbar with duplication.
In a lot of cases using badges and the onClicked event correctly can replicate a lot of the functionality of page actions in browser actions while using a combination of content scripts and message passing to trigger changes.
The StumbleUpon extension rotates its browser action's behavior depending on whether or not its toolbar is currently displaying.
We are programming a web application (not 'just' a web site, but functionality-wise a real application), and have the following discussion for the next release:
our UI designer wants to replace the browser's right-click context menu (showing our own menu where appropriate, or no menu at all) because he wants the web app to be more like our (existing) Windows app
our developers (and I) strongly object because this is bad practice, and simply something you do not do in a web application
Thus, I'm looking for "more solid" arguments - like best practice guidelines, any statements from reputable sources, coding arguments etc. - for the pros and cons of this issue, which I can hopefully use to resolve it once and for all...
You can't do that reliably anyway. In Firefox, go to Settings, Contents, JavaScript/Advanced (I'm guessing the captions, no English Firefox (; ) to override context menu behaviour and bang, your app doesn't work anymore. My online-banking application did this in their old version, so I couldn't do copy & paste with the mouse. I hated it, so I enabled the protection in Firefox and it worked. Kind of. Their new version doesn't do such bad things anymore.
Instead, use a little drop-down arrow where a context menu is needed, that can either be clicked or just hovered over to show the menu. JetBrains' TeamCity web app does that very well.
If your application is to run in an intranet, maybe the UI designer arguments are valid: as long as all of the users of the application are well known and you want to emulate some Windows application, I think it's ok to restrict the right-click or any other input, because it's just the requirements of this application, as it would be to any other app.
But if your application is to run in the internet, disabling or replacing right-click is a very bad idea, and these are only some of the arguments I reminded of:
First of all, changing the behavior of the user interface is aggressive and annoying -- no one wants to get used to "new controls" just to access your site, and generally people hate to leave their comfort area. I mean, I know what my right click does and I want it to do always the same thing.
People can understand the difference between Windows apps and web apps, so there's no need to "emulate Windows app behavior".
Not everyone uses Windows :-)
Also, this is innefective, sice there are several ways to overwrite this behavior, such as settings in Firefox or even plugins that disable specific javascript instructions, such as this one.
depending on your audience you stand a very good chance your users do not even KNOW there's a right click menu. So please don't make this the only alternative
I personally believe you should leave browser's default behaviors alone... users are used to them, so no need to get them used to your way of doing things.
However, if you're building an intranet (instead of a public site), then I'm for tweaking as much as possible to improve usability.
An argument I would use (in quotes for dramatic effect):
Lack of consistency & reduced
functionality compared to other
unhindered web interfaces will lead to
a loss of user confidence - which
is undesirable to say the least.
Of course, if many or most of the web application users are already familiar with or regular users of the Windows app, the UI designer could be on the right track and the consistency with the Windows app could be a winner.
That said, in my opinion it's hard to make a custom context-menu within a web page intuitive, and while some users might warm to it, I'm guessing most will probably never use it.
because he wants the web app to be more like our (existing) Windows app
I think right-click in a Windows app is a bad idea.
In a web browser it's a UI disaster because nobody will be expecting it.
I think it depends on whether you perceive the context-menu as part of the browsers chrome or not. If you do (and I ascribe to this view), then it should be off target, but otherwise it is a good place for adding some usability to your application.
Replacing the browser right-click context menu for specific areas of your GUI from your web application can be quite useful. Doing this just to disable the context menu will annoy your users, who may try to find a way around it. Also, removing or replacing the browser right-click context menu from the entire area of your application will usually be annoying and can make it more difficult to debug.
Unfortunately, I cannot offer any more solid arguments, and I'm not exactly taking either side of the argument, but I thought I would share my experience both as a developer of a web application and as a web user.