I watched a youtube video: http://youtube.com/watch?v=td_O6m6zDLo
It shows how NFC works with the device. Opening app and etc. But what if I want to develop my own NFC tag with functions like, for example, store user's Facebook profile link and when tap on tag, it will like a particular page.
Based on my understanding towards NFC, I have to write codes for the tag and the reader reads the codes in the tag and perform some actions or functions written in the tag (correct me if I am wrong).
I browsed through this website
http://www.buynfctags.com/bundles/gototags-nfc-encoder-starter-kit.html
and this
http://www.identivenfc.com/en/nfc-software-development-kit-sdk/nfc-solutions-development-kit-sdk.htm
My question is that can I develop the function mentioned above using the software from the website if I buy it?
Note that: It won't be an Andriod device. It will be like (I think) the reader and the tag. And I will be writing codes for the tag (correct me if I am wrong).
I assume you refer to NFC tags containing NDEF messages (as specified by the NFC Forum).
A typical NFC tag scenario would involve work on both sides, the tag and the reader.
You would create an NDEF message that you initially write on the tag. An NDEF message is a static data structure (see here) that could contain URLs, text, commands, data, etc. relevant to your application.
You then need an application on the reader side that reads the NDEF message from the tag, interprets the data structure and triggers some actions based on the NDEF message. Many smartphone platforms typically contain an application component that perfroms the reading and some initial parsing of received NDEF messages. Moreover, usually certain NDEF records are automatically handled by standard applications. E.g. URLs are usually automatically opend in a web browser, business cards are usually automatically opend in the address book app, etc.
If your target platform does not automatically handle a specific record type, you would need to write your own application that processes the record and triggers the appropriate actions. Similarly, if your platfrom does not automatically process NDEF messages from NFC tags at all, you would need to create your own application that does this.
Related
First, forgive my complete ignorance. I've tried to research this, but I clearly don't know the correct terminology for what I'm trying to accomplish.
I'm trying to set up NFC chips that link to separate, unique profiles. The profiles will be to a web app, but I want to hide the hyperlink to prevent someone from being able to copy the direct link to the profile and put it into another NFC Chip.
Example: A Plastic Business Card with an NFC chip that takes someone to a unique web app profile on their phone. I want to make sure someone can't create a new card and copy/paste the profile link into the new card on their own.
Note: The NFC Chip at this current moment will NOT be used for contactless payments.
Thanks.
So first point, security on NFC is hard, you can make it more difficult but not impossible to get the data from the card depending on how tightly you can control access to readers etc.
But from the sounds of it you are looking just to prevent casual copying.
It also sounds that you want the reading device to be a reading device.
So there are various techniques you can use to prevent casual copying, below I'll list a few in some order of complication (some can be used in combination with others):-
There is a common theme and drawbacks to some of these techniques.
You have to write your own phone App and get it to display the web App in it's own webview as you do not want the URL shown in a standard web browsers address bar.
Any protections you put in the phone App can be extracted from it by reverse engineering the phone App.
Use a NFC Tag like the Ntag21x range that has read password protection. You would write a phone App that knows the password to read the URL and then the App displays it
Encrypt the data on the card using standard encryption method and write an phone App that knows how to decrypt it and has the encryption keys to read the URL
Don't use a standard data format like Ndef but use your own data format again you phone app needs to know how you formatted the data to display
You can make reverse engineering of item 1 and 2 harder by not storing the "secrets" in the App itself but have it get it across the network at run time, but getting the secret can be reverse engineered or sniffed from the network.
I'm very new to NFC here. I am working on a project as part of which we are looking to do "check-ins" at a clients locations. We postulate we can use NFC tags so that people can scan them with their phones and easily "check in." The process after scanning would be to send the user to a URL such as example.com/check-in?location=PA&uniqueSerial=1234567.
Is there a way to get a unique serial number to place into the URL on each scan?
What I want to do is verify that the user has actually scanned the tag. What I don't want to happen is have users save the URL from the NFC tag and reload it again to create another "check-in."
Thanks for your help!
This seems to be an identical requirement to Prevent URL obtained from NFC from being shared or accessed remotely
And the answer is No,Yes and to some extent.
It depends on if you want to use a custom written App to read the cards or want to rely on the devices inbuilt behaviours to load the URL.
Most standard NFC tags just read and write to some EPROM data chips, so the data is static on the card, while most cards have a unique serial number this is still static data.
The possibilities are:-
1) Store a static URL in an NDEF message on the card that causes the device to load it in it's own browser - the URL is static and visible to the user for store and re-use. (That's the No response)
2) Write an App to read the cards, the URL can then be hidden from the user but still it will be unique to the card and static, but a determined person with the knowledge could work out the URL. (That's to some extent answer)
With Android you could use and AAR NDEF record to prompt the user to download the App if they don't have it already, not sure it this can be done on other devices.
2a) as 2) but then use the time or other methods to crypto hash the unique ID in time as well to make it a one time code. Harder for people to reverse engineer to but depending on how you do it determines the difficulty. (That's to some extent answer)
3) Their are some advanced cards out their that can run custom programs (one is called JavaCards https://en.wikipedia.org/wiki/Java_Card ), so you could write a program that generates a unique serial you want and then present it to the card reader device as a standard NDEF message that would launch the devices browser to this dynamic URL. (This is a Yes response but it very very advanced)
4) Instead of a NFC card being read from, you could have a smartphone with an App running Host Card Emulation software (or other device with a USB reader/writer might also be able to do Host Card Emulation). This is like option 3 in that the program that generates a unique serial you want and then present it to the card reader device as a standard NDEF message that would launch the devices browser to this dynamic URL.
This of course requires the device to be secured and powered. (This is a Yes response, but has drawback that it is not as cheap as a NFC card and needs it's own power supply and is advanced in terms of programming).
There are some fairly 'off the shelf' NFC chips that can do this. These 'authentication' NFC Tags are typically used for product authentication / counterfeit protection, etc. Example of use case on Seritag's website
However, I can't see that you'd actually need the backend auth to do what you want. Each time the tag is scanned it will generate a new unique auth code and as long as you log any previous codes then the user will always need the next one. Without the backend auth system it wouldn't stop the user just making up a new code but it depends how secure you want it to be.
Is it possible to get the amount of times an URL is received by a device from the proximity beacon API? I want to know what the click through ratio is of the broadcasted URL.
That depends. If you write your own app that scans for Eddystone-URL beacons and triggers some content (e.g., the web page itself) off of that, then naturally you're in full control and can implement this kind of analytics. Though it'll only apply to people which installed the app.
If you rely on Chrome for iOS, or the Physical Web iOS and Android apps to discover the Eddystone-URL beacons, then these apps do not provide any such numbers.
However, both Chrome for iOS and the Physical Web apps do fetch some metadata about the URL they detect, such as the page title and page description, without the user first clicking on the link. So there's a slim possibility that you could filter such requests out (they will be made by the Physical Web Service, or some similar "bot"), separate them from the actual visits, and do analytics based on that. Most likely however, this "bot," or the proxying service (which is there precisely to prevent this kind of tracking, and protect the user's privacy), will also do some caching, so you'll see fewer requests than the actual number of times the URL is received by the device.
And finally, dropping to a lower level, a note: most beacons are uni-directional, i.e., they broadcast information, but don't receive any information back, so beacons themselves usually can't count the number of packets on the receiving end. (I guess you could technically use the Bluetooth "scan response" mechanism to do that, but it would require custom beacon hardware/firmware.)
Unfortunately, no, it will not do this by itself.
Google's Proximity Beacon Api is a server-side system that stores metadata about beacons (location, battery level, etc) It requires you to add special client code integrated with your app to submit detection data.
Similarly, detecting Eddystone-URL beacons generally requires you to add custom code to your app to do the detections and and present the URL to the user. (The only exception to this is for some Chrome for iOS users with the Chrome Today widget enabled, and no public system provides click through rates.)
Since your app must present the URL itself you really have to roll your own solution to this problem.
If I understand right, you should be able to achieve this by Google analytics campaign. Setup a campaign, add campaign url to ibeacon url and you should be able to check the details analytics through Google analytics.
Apologies in advance if this question is a bit low end - I am only a quarter tech savy.
I am trying to produce some NFC enabled business cards and have been trialling some Mifare 1K compatible and also ultralight cards. I have been encoding the data using a Tag writer app via a Samsung GS3 and it seems to be performing well (ie when contact occurs the GS3 seamlessly asks which email account I would like to add the contact card too without requiring a particular installed app etc.
My question relates to a universal format for contact data that can allow the same type of outcome as occurred with the GS3 above with other phone formats when they inevitably become NFC enabled (ie Blackberry, Windows phone and the next I-phone). I have been reading about .VCF or Vcard as being the universal format however when I have encoded a mifare card with a contact card in this format and tried to get by GS3 to read it, the phone asks which application I would like to use. Is there a format I can use which will allow all phones to process and ask where the user would like to save the data without a tagreader app or similar?
Thanks
Brad
Unfortunately, there isn't a format that's universal for vCard on NFC tags. The closest thing to it is using a MIME type within the NDEF payload and referencing the vCard spec. The problem with this approach is that every cellphone OS or manufacturer may implement this differently.
The details lie in how the NFC standards body, NFC Forum, has not explicitly defined vCard as a Well Known Type. The format that data is stored on NFC tags is called NDEF. The NDEF specification lays out a structure and provides a TNF field to select WKF, MIME, EXT, and others. These TNF values map to what applications should process the NDEF data. In the case of WKT, typically a native application knows what to do with it (this is what you are asking for). However, WKT currently only specifies the following structures:
Text
URI
Smart Poster
Handover
Generic Control
Signature
Since there's no WKT for vCard, what Samsung's GS3 app is doing is using a MIME type. MIME has a similar structure to NDEF but not managed by the NFC Forum so Windows, Blackberry, etc. might choose to implement the vCard structure in a different way (using an EXT type, for instance) and still be NFC Forum compliant.
More about breaking down NDEF here.
From a web browser (Win/Mac) I need to launch a desktop application and pass it a response string (e.g. XML) from the webserver. For Windows, as far as I can tell I have two straightforward options:
Set the application as a default program, and respond in a standard way so the browser associates the response with that extension/Content-type. The browser validates the association, stores the response to a temp file and the app opens it.
Register a protocol, which causes the browser to launch the app, passing the URL to it. In this case apparently the string needs to be something like Base64-encoded (yet shorter than the browser's URL length limit). Otherwise I'd store the file on the webserver and the URL would be given to the app to request itself. This seems to be less than ideal, but iTunes uses it (itms://).
Which is generally easier to register by app installers across platforms? What I don't know at the moment is the particular installer framework being used by this app.
I have NO development experience with this but I think it's all about what you are developing and the business model.
Option 1
Would be useful when you create some sort of custom meta data file which can be viewed nicely in an application.
Company X has their own XML Schema's. Customers can download their data in that format.
Company servers serve these files with their registered/custom content-type. Customer can install an application that handles that content-type. Application development is focused on supporting the XML Schema's and build an interface upon it.
Option 2
Would be useful when you distribute content online.
Apple turned their iTunes business model into a protocol. So every channel (web,browser extensions,mobile apps,desktop,mobile sites,company devices,etc) they want market share can use that protocol. Application development is focused on supporting the protocol (business model) and build an interface upon it most fit for the channel.