Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I'm living in Ukraine and maybe you know that we have some serious problems in our country. Ukraineans nowadays have no rights and almost everyone who trying to do something about it(fight for democratic ideals) are treated as enemy of the state. Police kidnap own people and torture them in prisons.
I'm an author of Chrome extension and this is my way to fight against tyranny. Still i'm worrying for myself and my relatives that someone could somehow find my personal information through its page in the store. And you need a credit card to register chrome extension in store(onetime $5 payment) so all my information is linked to my account in store.
So my question is next: could my personal info can be found through extension page in the store ? And maybe there is a way to hide such info..?
You should probably use a completely separate Google Account than the one you ordinarily use for uploading this extension. The webstore does show other apps created by the same author, so if you were to upload multiple extensions from the same account, and it was known who created the other extensions, that would be one way to tie it back to you. The other things that could tie an extension back to you are the contents of the extension (e.g. if you had your own personally identifying information in the HTML or JavaScript embedded in the extension code). Another way that they could attempt to unmask you is by sending an email with a virus to this account (the webstore does provide a way to contact the extension's author, I believe).
Google does comply with valid legal requests. Interestingly, Google's Transparency report doesn't seem to show any data on requests for user data from Ukraine. I doubt that, faced with a request to de-anonymize a dissident who has otherwise done nothing wrong, that Google would comply. That being said, as a political dissident, it's always better to be safe than sorry. For making the registration payment, you might want to use MaskMe or a similar masking service. You might also want to use a VPN for all of this so that all your activities (both encrypted and not) occur outside of Ukraine.
Anyway, that is a very interesting question, and I wish you the best of luck in restoring santity and democracy over in that part of the world.
I would like to publish an app in google play, but I want to restrict the downloading under password or something like that. Is it possible? Is there any alternative?
Many thanks in advance,
Short Answer:
No.
Slightly Long Answer:
Applications available on Google Play cannot be downloaded only after a user authenticates. Any such feature will have to be implemented withing your application. At best, if this feature is needed for monetary reasons, publish a paid application.
Since the OP isn't descriptive beyond what you are looking for as a feature, it will be difficult to suggest an option / alternative that might suit your requirement. However, if you have a server setup that can communicate with the app, you can implement a feature which requires users, upon installation and running your app, to Sign Up for a new account and/or Login if already registered.
Again, I will circle back to the original point. Any such feature will have to implemented within the application itself. Google Play does not have such a feature.
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.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
Google Chrome showed me this message a small div kind of popup.
The upgrade completed successfully.
Google Chrome has successfully upgraded your extension with the new ToFind service.
Continue using toFind services
learn more
I don't know when this got installed I never installed anything during this period
I remember installing a software that installed the superfish search plugin(again without my knowledge).
Neither did Kaspersky detect it nor did Google Chrome give any warning.
I managed to uninstall it. But I still get the "find product" button on certain shopping website but I don't see any results.
Now this has come up in the last few days when I had installed no knew software.
I think Google Chrome is vulnerable to this spyware/spamware.
Don't even know what is is
Anybody seen this and know how to uninstall it.
It does not show up in the extensions. I have just a handfull of extensions
Gone through a lot of research basically found nothing on the web, after reviewing all programs installed and extensions for "ToFind" which gives no result.. and as suggested above removed all search engines (except google) from Chrome I still get the annoying floating search thingee on all http pages.
Went on and review the site tofind.info, where the search's setting is pointing to, which reveals a bit more info:
"...The "To Find" functionalities are added by browser add-ons and are available directly using "To Find" add-ons or by partners that publish their add-ons combined with the "To Find" functionalities to their add-ons as addition to their functionalities."
Now Im pretty sure this is something to do with the extensions I have, which may have been bundled with this service.
Once I get to this it doesn't take long for me to pinpoint it by disabling and enabling extensions... for me, it is the "BarDeCo: QR Code Decoder & Encoder/Generator 1.0.0.8" which I need to disable and remove that icon. The thing is, I had this extension for ages, but just recently this search thing pops up.. so it is a bit of annoying and is revealing some weakness in the control Chrome has on its extensions, it doesn't tell user what has changed (like android or iphone apps).
Anyway, hope it helps.
I just managed my search engines in Chrome settings and removed Live Search, Yahoo, and Ask.com from my default search engines, and the "toFind" button disappeared.
I didn't check after doing each one, so I don't know which was the culprit.
I left Bing and Google.
You can find them here: chrome://settings/searchEngines
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 9 years ago.
Improve this question
The HTML5 family of specs has several new communication capabilities, including XmlHttpRequest Level 2, Web Sockets, and Server-Sent Events. I can easily think of examples of web apps that I might like to build with these specs.
Edit: Here's some examples:
XHR2: search client, web mail, file uploader
Web Sockets: FPS, online games, chat client, NRT traffic or weather reports
SSE: Stock ticker, news feed, FB wall
But when it comes to the HTML5 Web Messaging spec, I can't think of any. So what kinds of web apps might I want to build with it? TIA.
http://www.w3.org/TR/webmessaging/
I use it to communicate between tabs. For example, when capturing an electronic signature, we open the document to be signed in a new tab. When they submit the signature, I message the main tab to let it know that the signature has been submitted. This allows me to take further actions on the main tab without having to do some convoluted server-side check via polling.
It's intended for cross-domain messaging. One big example would be Facebook apps, which currently have to communicate with Facebook via a convoluted manner as they live on a separate domain in an iframe.
I think all these technologies enable a more responsive web design. It's just like the AJAX transition: Before the transition, users expect to see the whole page refresh; After the transition, users understand the page can be updated partially.
When the new transition is finished, users will realize that content on the page could be real-time data. That means a user is not only interacting with a website (and then wait for other users to interact with the same website). He or she could be interacting with other users because it's real-time interaction over the website.
Cross-domain support will make this more widely adopted. Because not everybody will set up their own responsive web server and real-time web application, cross-domain support will allow those not-so-dynamic websites to integrate new features from 3rd-parties.
I recently found a good use case for Web Messaging. Many web apps are starting to authenticate using Facebook, so they open another tab with a Facebook login and communicate with the its contents.
Got a better use case? If so, I'll unselect my answer.