From MDN：
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Avoid using it and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.
Because it was replaced by Service Workers.
AppCache has a not so good API design and Service Worker can be used more flexible.
Trying to fix up an old Firefox addon which makes extensive use of the Google Maps API. However, AMO CSP disallows ALL remote scripts and evals. AMO CSP compliance required for addon to be signed, only signed addons allowed to be installed and run.
From AMO's validation feedback:
Security Tests 0 errors, 6 warnings, 0 notices
Scripts must not be remote
Warning: <script> tags must not be referenced to script files that are hosted remotely.
chrome/content/file.html
4 <script src="http://maps.google.com/maps?file=api&v=3&key=<...>" type="text/javascript"></script>
Is there any way to download, and modify the API into files for use in this environment? The project has had an API key for many years and used code remotely. I am just stepping in to help revive the obsolete addon. Beyond the technical, are there licensing issues with the code usage in this context? Currently licensed under MPL-1.0 but it could trivially be changed to MPL-2.0, which I am advocating as the path of least resistance.
To answer my own question, after further research, the best option is simply not to use Google Maps API, due to all the reasons mentioned above.
Not open source compatible [related question]
Not available for embedded applications
Not Mozilla Firefox Addons CSP compatible
EXTREMELY slow to fix SERIOUS security problems (eval-soup)
Inadequate update frequency or support
Prohibitively restrictive barriers to access
Inflexibile, unsuitable, undesireable.
What ever happened to the mantra, "Do no harm?" Has it become, "Do no good?" Anyways...
One of the many other free software libraries will achieve what I want.
I could bypass the whole issue entirely, and just present a text list of regions with check boxes for areas of interest, build a combined - possibly non-contiguous - polygon(s), and use any Geo capable polygon lib to check if arbitrary points fall inside or outside the boundaries of a polygon.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 13 days ago.
The community reviewed whether to reopen this question 13 days ago and left it closed:
Original close reason(s) were not resolved
Improve this question
What are the existing client-side architectures to access a local Smart Card thru a PC/SC Smart Card reader (ISO 7816-3, ISO 14443) from a generic browser (connected to a server through http(s)), preferably from Javascript, with the minimum installation hassle for the end user? The server needs to be able to at least issue APDUs of its choice to the card (or perhaps delegate some of that to client-side code that it generates). I am assuming availability on the client side of a working PC/SC stack, complete with Smart Card reader. That's a reasonable assumption at least on Windows since XP, modern OS X and Unixes.
I have so far identified the following options:
Some custom ActiveX. That's what my existing application uses (we developed it in-house), deployment is quite easy for clients with IE once they get the clearance to install the ActiveX, but it does not match the "generic browser" requirement.
Update: ActiveX is supported mostly by the deprecated IE, including IE11; but not by Edge.
Some PC/SC browser extension using the Netscape Plugin API, which seems like a smooth extension of the above. The only ready-made one I located is SConnect (webarchive). It's no longer promoted (Update: thought still actively maintained and used late 2020 in at least one application), it's API documentation (webarchive) is no longer officially available, and it has strong ties to a particular Smart Card and reader vendor. The principle may be nice, but making such a plugin for every platform would be a lot of work.
Update: NPAPI support is dropped by many browsers, including Chrome and Firefox.
A Java Applet, running on top of Oracle's JVM (1.)6 or better, which comes with javax.smartcardio. That's fine from a functional point of view, well documented, I can live with the few known bugs, but I'm afraid of an irresistible downwards spiral regarding acceptance of Java-as-a-browser-extension.
[update, Feb 2021]: This answer considered the WebUSB API as a promising solution solution in 2015, then reported in 2019 that can't work or is abandoned. I made a question about it there.
Any other idea?
Also: is there some way to prevent abuse of whatever PC/SC interface the browser has by a rogue server (e.g. presenting 3 wrong PINs to block a card, just for the nastiness of it; or making some even more evil things).
The fact is that browsers can't talk to (cryptographic) smart cards for other purposes than establishing SSL.
You shall need additional code, executed by the browser, to access smart cards.
There are tens of custom and proprietary plugins (using all three options you mentioned) for various purposes (signing being the most popular, I guess) built because there is no standard or universally accepted way, at least in Europe and I 'm sure elsewhere as well.
Creating, distributing and maintaining your own shall be a blast, because browsers release every month or so and every new release changes sanboxing ir UI tricks, so you may need to adjust your code quite often.
And you probably would want to have GUI capabilities, at least for asking the permission of the user to access a card or some functionality on it.
For creating a multiple-platform, multiple browser plugin, something like firebreath could be used.
Personally, I don't believe that exposing PC/SC to the web is any good. PC/SC is by nature qute a low level protocol that when exposing this, you could as well expose block level access to your disk and hope that "applications on the web are mine only and they behave well" (this should answer your "Also"). At the same time a thin shim like SConnect is the easiest to create, for providing a javscript plugin.sendAPDU()-style code (or just wrap all the PC/SC API and let the javascript caller take care of the same level of details as in native PC/SC API use case).
Creating a plugin for this purpose is usually driven by acute current deficiencies.
Addressing the future (mobile etc) is another story, where things like W3C webcrypto and OpenMobile API will probably finally somehow create something that exposes client-side key containers to web applications. If your target with smart cards is cryptography, my suggestion is to avoid PC/SC and use platform services (CryptoAPI on Windows, Keychain on OSX, PKCS#11 on Linux)
Any kind of design has requirements. This all applies if you're thinking of using keys rather than arbitrary APDU-s. If your requirement is to send arbitrary APDU-s, do create a plugin and just go with it.
Update (8/2016): A new API for the Web called WebUSB API is being discussed. You can already use it with Chrome v54+.
This standard will be implemented in all major browsers and will replace the need for third-party applications or extensions for Smard Cards :-)
So the new answer is YES!
And the OSI-like architecture stack is:
PC/SC
CCID v1.1
WebUSB API
USB driver, i.e. libusb.
2019 Update: As #vlp commented, it seems that it doesn't work any in Chrome because they decided to block WebUSB for smartcards for some specious reasons :-(
Note: Google annonced that they will abandon Chrome Apps in 2017.
Previous anwser:
Now (2015) you can create a Google Chrome App, using the chrome.usb API.
Then you access the smartcard reader via its CCID-compliant interface.
It's not cross-browser but JavaScript programmable & cross-platform.
Anyway Netscape Plugin API (NPAPI) is not supported any more by modern browsers. And Java applets are being dismissed by browser vendors.
I have just released a beta plugin addressing this problem.
This beta code is available here:
https://github.com/ubinity/webpcsc-firebreath
This plugin is based on the firebreath framework and has been beta-tested with Fireofx and Chrome under Linux/WinXP/Win7. Source code and extension pack are provided.
The basic idea is to provide a PCSLite API access and then develop a more friendly JS-api on top of this.
This plugin is under active development, so feel free to send any report and request.
For your first question I have little hope: either you are satisied with a very small subset of smart card functionality (like signing e-Mail or PDFs), then you may use some ready-made software (like PKCS), ideally maintained by the smart card company, or you want broader functionality and need to invest considerable effort on your own. Surely PCSC is the starting point to choose.
At least for your "also:" there is some hope.
1) Note, that some specifications (e.g. ICAO/German BSI TR-3110) request a method, where a PIN is not blocked, but uses a substantial amount of time as soon as the error counter hits 1 before replying. The final attempt must be enabled using a different command, otherwise no further comparison and error counter adjustment is done.
2) Simply protect the Verify command by requiring secure messaging. Sensitive applications use secure messaging for everything, so first step a session key is negtiated, which is second applied to all succeeding commands and responses. The effect would be, that the command is rejected due to incorrect MACs long before a comparison or modification of error counter is done.
There is another browser plugin similar to the one proposed by #cslashm available at http://github.com/cardid/WebCard. Is also open source and can be installed with "minimum installation hassle" as required in the original question. You can see an example of use visiting http://plugin.cardid.org
WebCard has been tested in IE 8 through 11, Chrome and Firefox in Windows and in Chrome and Safari in Mac OS X. Since is just a wrapper for PC/SC it requires in Mac OS X the installation of SmartCard Services from http://smartcardservices.macosforge.com
As chrome and firefox going to stop the support of NPAPI Plugin, there is no secure solution available to maintain the session for the smart card reading instead your certificate of the card have support for mutual ssl ,I answered for the similar question source,It might help
Its dirty, but if its acceptable / viable to install a bridge daemon/service on the client machine, then you can write a local bridge service (e.g. in python / pyscard) that exposes the smartcard via a REST interface, then have javascript in the browser that mediates between that local service (facade) and the remote server API.
Web Serial API (draft) can be used to communicate with a serial smart card reader from some browsers.
Buyer beware: This API is a draft and may be changed/abandoned at any time.
Speaking about Chrome, you can now use the Smart Card Connector app provided by Google which bundles the PC/SC-Lite port and the generic CCID driver.
The app itself works through the chrome.usb API, that was mentioned by the previous commenters.
So, instead of rewriting the whole stack (starting from the lowest level - raw USB), it's now possible for developers to code only the part that works on top of PC/SC API - which is exposed by the Connector app.
Clients,clients,clients...plugins,..JSApis..
Well..
For certain we know this : All browsers, when communicating to an Apache or IIS servers, are actually signing "something" when a https/SSL handshake process is needed.
For instance, a typical Apache configuration like this:
SSLVerifyClient require
SSLVerifyDepth 10
SSLOptions +FakeBasicAuth +StdEnvVars +ExportCertData +OptRenegotiate
Initiates a PIN pad pop up and the user must insert the smartcard pin to go on.
Well, my idea is : why not make the turn to the server, and tweak that behaviour, in order to upload a bytestream of stuff to sign something when a handshake is initiaded?
I have a setup where a smartcard reader is scanned to login a user. The PC/SC library work great on desktop. Somebody had mentioned to use
Emscripten (https://github.com/kripken/emscripten) compiler which compiles c++ into JavaScript code. But that didn't work well because some of the functions being used by PC/SC are only available server side.
After much research. I finally gave up on a client side solution, chrome web usb API also couldn't recognize the reader.
I then decided to give signalR a try and set up a hub on the PC connected to the smartcard reader and this approach worked out very well.
I have an instant messaging application almost complete the only thing I'm missing are firefox notifications for you. As is the API?
It's not clear if you're after Notifications API or Push Notifications API, so I'll talk about both.
First, the Notification "API" (I'm not sure if it's been renamed to be an API, and I'm afraid it's just known as "Notification" by now). You can use mozNotification to create new notification objects and use show to display them:
var notification = navigator.mozNotification;
var n = notification.createNotification("Title", "Body", "optional_icon.png");
n.show();
On both links, you can get a better understanding what can be done with this.
Be sure you ask for permission to use this (add this to your manifest.webapp):
"permissions": {
"desktop-notification":{}
}
To make it easier, I've made a demo app. That a look at how it works, and the changes I've made.
Warning: this is different from Web Notifications.
The Push API is already listed on Mozilla Wiki, but it's work in progress AFAIK. You can follow the news on this specific API on Mozilla Wiki, on github (server side stuff) and on the Gecko implementation bug.
There's another API, the SimplePush API, that seems to be working by now. Unfortunately, I don't know much about it. But at least the documentation seems pretty good.
Unfortunately again, I don't know how those APIs relate to W3C's Push API. I'm afraid the Push API is somewhat related to the standard, although I'm not sure of that. I wouldn't rely on any other documentation besides Mozilla's, in the case of these APIs.
For server based push notifications see Simple Push that includes implementation examples. This is available in Firefox OS (/Boot2Gecko) 1.1. but not in 1.0 (which is on all currently released devices).
Please also note, that you'll need a real device and it won't work in the emulator.
Simple Push itself is not difficult to implement given the above link. Nevertheless there a couple of things you need to take care about:
you need your own server that will trigger Firefox's server on demand for a push
the push received on the device does not contain any information (this means you'll have to query needed information after receiving the push)
the push received is silent and invisible - that means you'll have to display a desktop notification yourself as described above
the push endpoint has to be the same page as your launch_path from the manifest (this means you'll have to put all the logic in one page) due to a bug
make sure you'll acquire a wake lock after receiving the push and release it after your work is done - this way the device will not fall to deep sleep and your push processing is paused in the middle of it
It is possible to build similar functionality on Boot2Gecko 1.0 using MozAlarmsManager.
Today I noticed that in the Chrome web store dashboard, under my extension's settings there is a check-box labeled "Ads Behavior", and whose description is "This extension injects ads into some third-party websites.".
My questions are:
Can an ad-supported extension inject advertisements in a page visited by the user?
If so, what is an acceptable policy?
Can the extension replace existing advertisements (even though that seems to me kind of unethical/stealing) or must it only create new ones?
Is it possible to use any ads network or must it be adsense?
Thanks
Is it possible to use any ads network or must it be adsense?
Actually it can't be AdSense. It's specifically mentionned in their program policies:
Currently, we don't permit Google ads or AdSense for search boxes to be distributed through software applications, including but not limited to, toolbars, browser extensions and desktop applications.
I wonder if any ad provider allows such a thing.
Can an ad-supported extension inject advertisements in a page visited by the user?
The fact the checkbox exists suggests it's acceptable as long as you declare it, so users are aware of it.
If so, what is an acceptable policy?
I would argue anything that makes it clear to users what you're doing and follows the terms of the ad network.
Can the extension replace existing advertisements (even though that seems to me kind of unethical/stealing) or must it only create new ones?
Agree it's unethical, most content and apps out there cost money and it deprives publishers. But as with a lot of extensions, it's seen by the browser as the user's choice. That's basically how the web works - users have control over the client. The most popular extensions for browsers are ad blockers, so I doubt the Chrome team would ban an extension that swapped ads. Please do consider the website owners though. Adding ads is at least better than replacing them.
Is it possible to use any ads network or must it be adsense?
Any, I'm fairly sure. Google wants Chrome to be seen as generally independent from its services. You'll even see Google's various competitors promoted in the Chrome Web Store at times for that reason.
*However*, there's a big caveat here. It's very possible this kind of ad injection is forbidden by the ad network in question. It's certainly the case with many affiliate links, that you can't just inject your own, or swap in your own, link. The argument is the user was already going to click on it anyway. So if you're injecting ads, the biggest constraint is going to be your ad provider, not Chrome.
I too had concerns about this, specifically a Chrome app extension called Bookmark Sentry as while it does do a great job of managing your bookmarks, it also injects itself and intercepts advertisements replacing it with it's own affiliate network.
Specifically in viewing the source code it appeared to contain a 'whitelist' and 'blacklist' of sites to intercept advertising while navigating. The user is given the choice to opt-out of advertising in settings but it is poorly explained as 'marketing' with no explanation as to what it is doing.
I raised concerns to Google Chrome through flagging of abuse. Through a contact I was informed however that:
"Ad injections are not in violation of the Chrome Web Store program policies. The policy requires that ads must be presented in the context of the extension or, when present within another page, ads must be outside the page's normal flow and clearly state which extension they are bundled with. We believe that ads are a legitimate way to monetize, but that they should be a known cost to the extension user."
So in this particular case at least, Google viewed it as acceptable, curiously both Kaspersky Labs and Microsoft Security Essentials reported this immediately to me as malware and removed the Extension.