Sunday, July 29, 2007

Mobile Code Scanning: Selecting the Technology

Image Attribute: OrangeJack, FlickrSelecting the code scanning technology for your campaigns is a critical step. There are key factors in making that decision, and those, to mention two, are the code format and the features that the complete solution can offer.

To accompany the technology+vendor selection process, a good thing to do is to have the vendor list handy, and fortunately Scoot Shaffer in his Blog had composed a long list of code scanning vendors. Many vendors support standard code formats (QR+DM) while others have their own proprietary code format, plus optional support for the standard codes.

The code format has implications on the user experience, the value driven through simple or complex use cases, through to the control an operator has on their ecosystem and the ways in which revenue can be generated.
The following are the key factors when looking at code formats:
  • Standard vs. Proprietary: That's probably the key decision to be made. Today there are two leading open-standard code formats: QR and DM. Both are old timers: QR has been largely successful in Japan and DM has had its own successes. What you want to keep in mind as you make this decision, is that in every emerging ecosystem, there would be two types of solutions: The first would be the existing solutions that were "loaned" from other industries, those would typically have significant traction by that time (otherwise nobody would "reuse" them) and in some cases they might be open standard. New solutions will have, by definition, less traction, they would typically be too new to be open standard. But, new solutions would almost always be optimized to the objective. So it's up to you whether you want to optimize the technology to what you're trying to achieve, risking it's immaturity, or you go down the safe route with open standard codes. If you chose the standard codes you can stop reading now, choose QR and/or DM and move to the next decision. If you want to learn the differences that new and innovative solutions create, keep reading.
    A note has to be said here about the 'Mobile Code Consortium', trying to make sense out of all of this. On one hand, recognizing that advertisers are the gold pot and they would not be in the game if the market were fragmented by different codes is a strategic required decision to be made. On the other hand, this is not the first time that a consortium is gathered in a very early market. For more reading on this, Scott Shaffer had made a good post on this and so had I, and the bottom line is, when you look into this consortium, make sure you are comfortable with the forum, timing, agenda (which is public) and their motivations.
  • Scanning Performance: Once of the objectives you want to get from code scanning is how easy it is to scan codes. This should be an obvious operation for a non-trained subscriber. It should be immediate to an enterprise user. You want to find codes that were optimized for "real human hands" environment, where everything goes: blur, rotation, angles, slight motion or shiver, different lighting and shading conditions etc. You also want to find the decoding application that provides a timely response rather than choking the phone's CPU for several good seconds.
  • Code size has reach implications: Certain codes compress information better than others, so that the resulting image (usually measured in modules) is smaller. typically, codes would grow in size in proportion to the amount of data you try to put into them. In code scanning, there's a couple of parameters that count: How many pixels can you get from the phone's camera API and how many modules does the code have. what the decoder needs to be able to do is to contain the complete code in the image, and be able to determine each module. For that, there is a sweet-spot of how many pixels-per-module would optimize the probability to successfully decode the code. If you have a code format that does not compress well, the code would be large, and low-resolution phones would just not be able to scan that code.
  • Information Reliability: OK, so you've successfully scanned the code, hooray! But-are you sure you got the right data? Error detection and correction algorithms are a must-have in code scanning systems, make sure they're there.
  • Better Data Compression drives Flexible Use Cases: The better compression the code uses, the more information it contains per given size, the more data the code reader application can have immediately after decoding the code. The result is comprehensive UI that is more user friendly, and more complex, valuable use cases: anything from launching a local file on the phone to triggering a mobile payment transaction, including the merchant, the user, the amount and security fraud-prevention data, all of which can finally be transmitted over SMS to the mobile payment backend system.
  • Aesthetics: Finally, one of the key features of the codes being a visual entity, is how can they be visually pleasing to the subscriber. The typically scenario would be that these codes would be embedded into an ad, and it is expected that the subscriber would be triggered to scan the code by the context of the ad, not by the code itself. Advertisers would be highly aware of the space the code takes and how does it embed well in the graphics of the ad. They would be surprised to see how their logo embeds in an interesting way into the code, or the code into the logo. Therefore, aesthetic features like code shapes, code coloring, module shapes and coloring and others are likely to be of high value to advertisers.

There are probably more code format features, but let's turn the attention now to the solution features that are important to look at:
  • Direct vs. Indirect resolution: The resolution point is where does the code content translate into an actual action, like launching the browser to a URL, adding a contact to the address book, sending an SMS etc. Some code formats only allow limited data to be carried in the code, such that essentially the code itself would typically only contain some index, the code reader application on the phone would connect to a web server ("Central Resolution Server") to say what action is associated with this index. This is called "Indirect Resolution". In contrast, code formats that allow more data to be carried in the code, in some cases allow the code reader to translate and take a local action, immediately on the phone without necessarily having to connect to that resolution server. I call that "Direct Resolution". For example, if we're looking at an SMS code, if the code can contain something that tells it's an SMS, and then the target phone number and the content of the message, then there's no need to connect to a remote server to send the SMS. There are a couple of differences in comparing direct and indirect resolution:
    • Direct resolution provides immediate value to the subscriber: when the subscriber scans the code and they immediately see what the code does (for example, see the SMS message composer screen pop up) that immediacy is very pleasing to the subscriber. using the indirect system, having to connect to a remote resolution server to resolve the index BEFORE the user even knows what the code does, is somewhat degraded user experience.
    • Reliability: The indirect resolution system relies on the user's patience while the phone attempts to connect to the remote resolution server, that the user indeed has data plan and is in data network coverage area and so forth. the direct resolution system is autonomous for those codes that contain the data.
    • Use cases include local actions: the ability of the code reader application on the phone to scan a code and have all the information it needs, means that the code reader, being an application running on the phone, can take any action using the phone's resources: launching a local multimedia file, adding a contact to the address book, adding a meeting to the calendar, sending an SMS and much more. More important, complex use cases can be thought of where the combination of the data in the code, samples of the user's context (location, time etc.) and collecting user input can be performed before taking the action. Typically, remote resolution systems launch the phone's web browser and from there the actions that can be taken are somewhat limited.
    • Monitoring: to the benefit of remote resolution systems is that they inherently provide monitoring and reporting mechanisms that, if installed on the code reader application, might be unpopular by users who would find out about them.
    • Registration and maintenance: Usually the location of the resolution server is a powerful negotiation point. Who controls that server, how is it being maintained, can users create codes or brands only. All these are valid questions to be asked and they have a lot of bearing on the business models that are created finally.
  • Support for subscriber code creation as well as enterprises: the architecture of the solution is very important factor to look at. Whether initially subscriber code creation tools are important or not, for example, to encourage adoption you will want subscribers to get familiar with code solution and promote it to their friends.
  • Reach: You will want to maximize the effect on your subscribers. You want to choose between support for all your new phones that are sold in stores, or support for a high chunk of your install base. there are different mobile operating systems and you want to think how to maximize the potential of this solution. Reach is very important to subscribers' friends...
  • Control on your ecosystem: This is probably one of the most important issues you want to look at. Essentially, if you're working with open-standard codes, everyone can create those codes, everyone can scan those codes. Well, what if you need some control? For example, you have an SMS-based mobile payment system. the parameters of each transaction are made of the vendor, the price, the product and the user identity. You will not want someone to decipher your codes, change the price and attach it to products, would you? Some proprietary code-based solutions allow you to have better control on who creates codes, who can scan which codes and what happens when an authorized user scans that code, or an unauthorized user scan that code. with those systems you can fully customize the user experience so that it is predictable, user friendly, you can control the user input collection, you can add hidden security information for fraud prevention, for example, and you can control the resulting transaction.
  • Support for open-standard codes: If you have gone down the road of choosing a proprietary code format-based solution, you may be anxious whether that code format will make it successfully. In that case, you may want to ask the vendor whether they support open-standard code formats "just in case". If they do, you can launch your solution with confidence that you have an optimized solution and a fall back if all hell breaks.
I hope that provides a pretty good coverage of the issues you want to put on your check list when selecting the technology. You want to keep in mind the business goals and the revenue streams I discussed in an earlier post so you don't get lost in the technology maze. A successful solution is not necessarily the technological robust one, its the one that makes sense to your audience and your organization.

In benchmarking different technologies you want to research the web, you will find that independent academic researches have been made on different codes, you will find that creating codes yourself and downloading the matching code reader to your phone will give you a lot of insight into how this thing really works and from there you can evangelize on innovative services in your ecosystem.

On the next quick post I will talk a briefly about vendor selection, and specifically discuss how sometimes technology "features/limitations" (you pick) mandate the vendor's business model with the operator.

I hope you found this useful, thanks for reading!

19 comments:

Swampthing said...

Amir,
Great article. IMO, the only bad thing about your article is that you seem to think that Scott Schaffer is telling the whole truth about ALL of the Mobile Marketing companies. I have read before that he misleads his readers, and, covers the truth about Neomedia Technologies. Such as quick links that take you to the Cornell site, Neomedia's financial backer, and other links that do not work. Hey, I do not mind honesty in reporting, but, to publically mislead readers about one of the companies is wrong. Whether if it was done intentionally or not I would think twice about posting anything related to him because it would seem that he has a one sided view and he has something to lose, IMO.

Anyway, this was not meant to be a personal attack on Scott Schaffer. He once backed Neomedia and promoted them to Microsoft's Robert Scoble who called this the next 'killer app' for mobile. I do not understand what changed either of their views.

Whether or not I am a shareholder in Neomedia, it seems as though they have a great IP and others are seeking a way around it.

I just hope that sometime soon a agreement can be reached so that the mobile web user / consumer can be linked in one click.

dlethe01 said...

AFFM was created in 2005 by this group (French operators):
Auchan Telecom,
Bouygues Telecom,
Debitel,
NRJ Mobile,
SFR,
Orange France,
Virgin Mobile,
l'ACSEL (Association pour le Commerce et les Services en Ligne),
le GESTE (Groupement des éditeurs de services en ligne),
des éditeurs de services mobiles et prestataires techniques.
http://www.flashcode.fr/qui/

AFFM has tested different barcode readers in order to define a standard in 2008.

Scanbuy has associated with Wister to commercialise Hotscan reader in France. Guy Nicolas is the founder of Wister.
http://www.hotscan.fr/hotscanv2/index.php?option=com_content&task=view&id=19&Itemid=25

Hotscan can read flashcode barcode. Why? It seems that Wister/Scanbuy has partnered with SFR. Only Mobiletag and Hotscan readers can read Flashcode. Mobiletag has partnered with Bouygues Telecom and Orange France.

Kaywa, ConnexTo, Glass (Lavasphere), Myfreetag (lavasphere)...can not read flashcode. RedShift, a French startup, has used Gavitec's lavasphere (Myfreetag).

We strongly believe Scott Shaffer is a shareholder of Scanbuy. It is quite strange that Scott Shaffer has never talked about the AFFM group. He has preferred talking negatively against the MC2 (Mobile Codes Consortium).

Amir Rozenberg said...

Swampthing, Dlethe01,
Thanks for your comments, let me try and address them:
First, who Scott Shaffer works for is irrelevant to the matter. The discussion here is about mobile code scanning. I am guessing your comment refers to the MC2 initiative and Scott's comment on that, which frankly, I share some of it. I can only suggest for any mobile space experienced player to remember what happened in other occasions where similar initiatives took place early in the game (PoC?). Just ask yourself what is the validity in the forum, timing and agenda.

Second, I think it would be presumptuous to suggest that one vendor/solution or another does not scan this code or that, especially when you're talking about "FlashCodes", which are basically DataMatrix open-standard codes, tied in their belly to someone's centralized resolution server. Nextcode certainly has the technology to decode QR and DM, would you like to try it? :-)

brewskih said...

Amir,
Your discussion is spot on. Adoption comes from the end users and not a consortium. And as you suggest, the standards then evolve based on what the end users are more appealed to.

So if there were 10 barcode readers out there, and the users were all using just one mainly, the standards would evolve around that one that is popular with the consumer. After all thats what this technology will evolve around is the consumer.

Then there is the issue of this universal reader "COMING SOON" by Gavitec. The last CC and the one prior to that, the CEO stated they have no date when this reader will be available, yet certain shareholders of NEOM for several momths now, on every blog have been touting it as coming soon. Soon is in the eyes of the beholder I guess.

And as to your remarks about open source codes being direct connect versus a resolution server are spot on as well. Those shareholders commenting here and elsewhere, dont want to acknowledge NEOMs patented process "REQUIRES" a resolution server or 3rd party intervention. Data Matrix and QR do not require such a server and therefore dont fall under the NEOM patented process. Therefore this technology is available to advertisers without the need to contract the 3rd party with the servers, since the QR and Data matrix can take you directly to content and bypass that middleman.

Its appalling that every blog attempting to have real discussions regarding this space, is overrun by these shareholders attempting to turn the discussion into NEOMs superiority in the space, when in fact to date NEOM has very little going on in the space with their QODE application(patented) and only their sub GAVITEC is making headway with their code reading equipment.

streetstylz said...

For more information on the Mobile Codes Consortium (MC2) please visit:

http://www.mobilecodes.org

http://www.slideshare.net/qode

Best,
Sean

dlethe01 said...

I am not going to pretend that I am an expert. I am here to learn.
However, I have never said Connexto code reader can not decipher Datamatrix and QR.
Jim Levinger, CEO of Nextcode, has also promoted his company. I have almost read all Jim Levinger's comments on different blogs/forum. Jim and Roger Fischer have different point of view (Proprietary vs standard code).

Furthermore, I know that Flashcode (2d code created by AFFM group) is a Datamatrix code. However, Flashcode also means 2d barcode in French. There is a confusion for people who can speak French.

I also know Hotscan technology: "La lecture du code-barres s’effectue via un mode indirect: les codes 2D ne codent pas directement une URL mais une référence hexadécimale." INDIRECT MODE
http://www.hotscan.fr/hotscanv2/index.php?option=com_content&task=view&id=12&Itemid=8

Thanks for your help. I had known all this (AFFM/Hotscan/Mobiletag technology) before reading your comment.

Swampthing said...

What did happen back in 2004 when there was a LOI agreement between Neomedia and Nexcode?

Does anyone know what happened? Is there still an agreement?

What relationship do they currently have and are they moving forward together?

How does M-Code, Qode, Lavashpere, Glass, and all of the others come together to benefit all?

Why not work together to provide (1) answer to all solutions instead of having multiple readers and multiple codes.

Isn't that what MC2 is doing?

Taking a picture and getting the information sent back to the mobile, IMO, is the best for the brands. If not, why not?

Open is great for individuals. Open is great, if I own it and people can click on my code to go to my site. If I want to change it I can do it when ever I want.

If I have an open code am I going to care about what platform I use to open any code, no. Just as long as the code I click on opens to content anywhere I go.

Why does this formation and development of the MC2 bother the small group of open source pushers.

Is it the fact that one company holds the IP that links barcodes to the mobile internet? Just asking.

Brewskih said...

In4it,
There you go again with the misinformation, after being corrected many many times.

You stated matter of factly one company owns the IP connecting barcodes to the internet. No one company does not.

Thats what this discussion is all about. Open codes do not require any IP patents to connect the barcode to the internet.

The one company you speak of owns the patents for a specific PROCESS which can connect barcodes to the internet.

Other companies are using the open source codes which do not require that patented PROCESS to connect a barcode to the internet.

Data Matrix connects directly to a web site if the URL is embedded, without using this patented process you speak about. QR codes with the URL embedded connect directly to the internet without using this patented process you speak about.

I know good and well you understand all this, and have been corrected on it for over a year now, yet you still keep posting the same false info on these blogs whenever anyone tries to discuss open satandards.

So the real question you should be asking is just what are your motives, to continually put out information you know to be false, other then the fact you own NEOM stock?

I think I read somewhere that putting out false information knowing it to be false is illegal activity from a stock holder.

By the way, you also say why not all work together to have 1 answer to solve everyones problems. Question for you. Is their only 1 accounting software program available for your computer? Is there only one browser available for your computer? Is there only 1 email program available for your computer? No, there are many of each catogory and the user decides what works best for them. So will be the case with barcodes and bar code readers. Adopting standards wont change that, it just means all will function in basically the same way as the competitors version.

As for NEOMs great IP you mention, its a 3rd party resolution required that many marketers will reject, and instead ipt for the open source code of the data matrix or qr codes. But the battle over which of all of them will win out is still a long time in coming here in the US, but my money says it will be the openb source codes in the end.

Yeah I know some of you have said that NEOM will combat that by developing an open source reader that you all are calling the universal reader. That product when developed will be coming from Gavitec, and has little to do with NEOMs Qode except that it will be able to read those AZTEC codes NEOM uses in QODE. So the real question is, readers aside, what has NEOM got to offer the shareholders when it comes to their core business or QODE, formally known as paperclick? The answer is nothing, because to date QODE is a non performing, non revenue producing application as best we know from the financials. Prove me wrong.

Amir Rozenberg said...

Swampthing,
I think there is a consensus that the motivation to have one code format and one code reader is a good and correct thing. The issue with MC2 right now is that some people believe it is simply too early to determine what works and what doesn't. It's not like a wireless protocol that engineers can sit in a room and dictate what will work in the real world. Some experience with real subscribers is required before making determinations on what works and what does not. unfortunately, dealing with these early markets requires some trial and error that does not come cheap, but will pave the road for those solutions that will get used.

streetstylz said...

NeoMedia's co-marketing partner Mobalis is doing a great job saturating the Latin America market with mobile code initiatives.

http://streetstylz.blogspot.com/

Best,
Sean

Swampthing said...

Amir,

Now, I have had chance to sit down and reread all of the comments today.

First, you are wrong that my first mention of Scott Schaffer does not go back to his comments about MC2. It simply goes back to him hiding the truth about Neomedia being a PWC player. WHY?

Again, He and others mentioned Qode was the 'next killer app'. Some, or maybe just me, would like to find out what changed?

Why did Mrcrosoft drop their AURA project?

I, almost, agree with your second comment. There should be multiple codes, but, there should be one reader for all. Why? IMO, whether I travel to China, Europe, or US the reader should cover all codes.

I agree that it will take time to get all of te real world experience and input.

Everyone, that I have read up on, has been invited to offer input to help make the Universal Reader. IMO, that 'reader" is going to be more than just a reader for 2D, QR, and data matrix barcodes.

IMO, that reader should be on every device by every handset manufacturer to turn on the internet of things.

Bruce, I would rather not respond to your direct comment, BUT, I would like to say, IMO, without IP in the U.S., a small business gets lost in the ocean of big business. Is HP, Nokia and others working with that company, YES. Simply put they are building the Universal Reader around the IP, WHY?


I can see the reason and timing for the forum and the cause.

There are a million questions. None of which I have the answers to. One must seek to find truth.

When one can travel abroad and click on anytihng in "one click" and have instant information, then there will be success.

Anonymous said...

The difference between Direct and Indirect (NeoMedia--which CAN ALSO be Direct BTW!) solution is that with Direct the URL is encoded into the 2D code. With Indirect the 2D code is decoded via a responding server. So why does this matter you ask?

Simple, with the Indirect solution the response can be dynamic--meaning that a different URL can be generated based on location/language (i.e. US, China, etc..), carrier (i.e. Cingular, Sprint, etc...), or even device type (i.e. Motorola, Nokia). With the Direct solution you get ONLY one URL for ONE code so campaigns cannot be customized or dynamic or most important-- launched WORLWIDE with ONLY ONE CODE. The only solution that Direct can offer is to link to a single WAP site. Also with Indirect, you can tell if the same phone has clicked on a 2D code prior to routing to the destination URL for an even more customized response. With Direct only the destination server could tell if the device has visited more then once. This is extremely important again for generating dynamic, useful responses. 'Indirect' requires ONE CODE WORLWIDE to generate an infinite number of unique WAP site responses while 'Direct' requires many individual codes WORLWIDE linked to many individual WAP sites to generate ONLY A SINGLE, STATIC RESPONSE. Indirect is to be preferred IMO especially when taking into account user preferences for privacy, which is NOT built into the Direct method either AND CAN ONLY BE ACCOMPLISHED WITH INDIRECT. :-)

Brewskih said...

In4it or Swampthing,
Again you demonstrate your lack of understanding of the technology.

At this time QR codes and Data Matrix codes are standardized in their respective parts of the world. QR has unique abilities the Data matrix doesnt have when it comes to asian characters and thus has become the STANDARD in the Asian part of the world. Data Matrix has become a standard code in the other side of the world.

This was all done without a consortium to adopt standards. And the fact is that consortium is not attempting to narrow the codes down to one code and one reader as you stated in your last reply. Their mission is to set standards for MULTIPLE codes so they will be workable on multiple platforms. Has the consortium put out a statement that their intent is to limit codes to ONE code?

Secondly, the same is true with code readers. You keep inferring their can only be one universal code reader. This is false, as I pointed out yesterday. Ten companies can develope 10 different readers that are all universal readers(based on the definition of UNIVERSAL as we know it), and still all be operating on the same set of standards set by any body or consortium.

As to Universal and what it means in the bar code industry, it dont mean ONE as you imply. It means that reader will be able to read all open source codes which have been approved as standards around the world. Thats why this reader you mention that NEOM/Gavitec are working on will read Data Matrix, QR, AZTEC codes as 2D formats, because they are all standard codes to date. Notice they didnt say their universal reader will read only NEOMs AZTEC codes which they use in their process. Thats because the reader wouldnt be a universal reader if it only read one standardized code.

So your theory that there must be one code and one reader isnt even supported by NEOM/GAVITEC or the Consortium they are working with.

As to the comments by anonymous, this discussion has already been had in several forums as well, which this blogger took part in and even the senior officer of one company stated in his blog that yes a QR or Data Matrix can be dynamic, just as these so called indirect codees can be.

First of all the demographic information can be stored on the cell phone in the decoder, which identifies the user as male or female, age bracket, location etc. Then the barcode can be coded with multiple links based on that info and there is plenty of room in the code to contain the sufficient amount of info to take the user to the proper web site based on their demographics.

Second the actual web site can be changed with a simple redirect if one promotion ends and the retailer or marketer wants to continue to use that same 2d code for a different promotion, with a different brand, product or any other cause. The redirect involves the same processes that are required to cahnge a code destination using a resolution server. Someone actually in either case, has to go into the data base and redirect that code to a diffent web page address.

So both direct and indirect codes are dynamic, and those who are heavily involved in this technology know this to be a fact.

Amir Rozenberg said...

Mr. Anonymous with the 'direct vs. indirect' comment,
Thanks for your comment.
I would suggest another way to look at this issue:
Direct resolution, to me, means that the application on the phone knows immediately what to do with the code, because the code has enough information to support that. The implication here is limited if you're thinking codes sole purpose is to link to content on the web. However, if you extend the codes functionality outside of that scheme, for example, launch a local multimedia file (take a museum scenario), launch an application, add a meeting to your calendar, mobile payment solutions and much more, then indirect remote resolution is simply limited in that respect.
Second, direct codes can certainly support that "one world URL" scheme you're suggesting. Nobody said that the URL encoded in the code is not in fact a redirection server address...
Hope that's useful,
Amir

Swampthing said...

Amir,

Great discussions. Thank you for keeping this debate around on your blog. I think that this is great to discuss these items.

This is my opinion on the whole topic: I think that there will always be disagreements on whether direct and indirect models are best for mobile marketing.

I want to be free to do what ever I like, make my own codes or click on what ever I want to get information. I am in favor of individuals creating their own tags to pull information. The Universal Reader should read every codes, of any type, whether I am in the U.S. or abroad.

In mobile marketing there are going to have to be rules to reach the consumer.

Mobile marketing, IMO, should be permission based. If the direct model is created or accepted it leaves the potential for big problems such as:

1.) Viruses, could be embedded in the tags. Once clicked your personal information could be pulled fro the cell phone. Now, I am not saying that this will happen. Is the possibility there?

2.) Spam. Once clicked the tag could be embedded with a multitude of click thru ads prior to the consumer ever gets to the product information.

Should there be a warning label that pops up to warn that the consumer may be clicking on a code that could potentially damage the software on their phone?

What is the potential for abuse for the direct model?

Please, forgive my multitude of questions for I am not dead yet and continue to learn every day.

Amir Rozenberg said...

Swampthing,
thank you for your recent interesting comment. Here's my view of this:
1- I agree, we will probably not agree on the best way forward until we have had some traction with subscribers and know what works. this is the case why IMO MC2 is too early and nobody should take decisions in a vacuum.
2- It is instrumental to understand that the direct method supports both direct URLs but also indirect URLs. Nobody said that the URL should not be in fact a redirection server.
Hence direct encoding is as applicable for 'universal URL'.
3- Following the thought, I don't see how could a code reader distinguish between a malicious URL and a valid URL, whether it is direct or indirect encoding. If anything, using direct encoding one could see immediately that the URL contains, for example, adult-oriented words and not launch that URL. In the indirect encoding scheme the user has no way of telling the destination URL until they are in it.
4- The spam/virus discussion is an interesting one. By providing local features that aren't necessarily URLs, such as adding a contact to your address book, you are providing more functionality. ALWAYS, when you are providing more functionality, it comes with increased risks. what would you choose? not adding that functionality to differentiate and sell more of your product, or would you take that step, provided that you make certain efforts to block malicious codes?
So I guess the answer is that one have to 'pick their poison', stay blocked to quasi URL-only approach, or open a very flexible system with potential risks that need to be objectively met.

Brewskih said...

Swampthing,

The threats you mention of virus' and spam will occur regardless of whether direct or indirect methods are used.

The situation will be just as it were with the internet. As these potential threats where increased on the web, the service providers started stepping up to the plate offering features such as sapm blocker, virus protection and ad blocking. But these features didnt come about at the beginning of the web era, they came many years later when the demand for them became apparent.

The same will be the case for cell phone technology. The day will come when your service provider will be offering spam blocker, virus protection etc as a part of your monthly cell phone package. To date there arent enough users using these features to warrant the research and developement of such programs, just as was the case with the web. Therefore its the individuals responsibility to protect their equipment, just as its the individuals responsibility to protect their computers.

But knowing for years that virus' and spam were out there didnt stop individuals from using thyeir computers, just as it wont stop them from using their cell phones.

And for what its worth, I believe the US congress has already been working on anti spam legislation for cell phones, since this spam uses up minutes costing the consumer additional fees, unlike the web.

Virus however will always be around in any and all types of electronic technology, since there will always be evil doers out there in the world. The only solution will be to try to catch it at the server, whether its a direct server for a company such as GE or the many others whose servers you pass through to go to their content, or an indirect server directing you to a 3rd party site.

As Amir has pointed out, with the indirect method you have no idea whether the code is taking you to a rogue site until you click on it and its too late. The direct method your phone will display everything in the code so you at least can feel a little safer on where the code is taking you.

Bottom line is you will never be safe on the web, or your cell phone, because there will always be someone out there developing malicious code for both, and there is no way to stop them from launching it to some degree or another. Only solution is once its out there and recognized, a quick solution is found to combat it.

Rich said...

Dear Anonomous,

Let me tell you why you are wrong and that Direct URLS can CERTAINLY be dynamic.

1. The language supported on the phone is located in the WAP header. No need for special indirect method.

2. The HTTP_VIA Wap header will provide you with the carrier and country. No need for special indirect method.

3. The UA_PROF will provide you not only with the the Handset manufacturer but with the handset model and capabilities. No need for special indirect method.

4. A WAP page can certainly be launched worldwide.

5. An LBS based barcode solution would have to get the Location info from the handsets GPS rather than from network based LBS lookup. Do you think the network would simply provide location data to every marketer who bought a indirect barcode solution... I think not. You can also get the location by asking a person their zipcode, phone number or sometimes it is already provided by the carrier.

6. Regarding 'malicious urls', they will and are currently installing content ratings at the wap gateway level. It would be fruitless to try to block adult content at the barcode/redirection level.

Conclusion: I think the only benefit of the indrect method is counting how many times a person re-clicks a link.

Anonymous said...

I found this site using [url=http://google.com]google.com[/url] And i want to thank you for your work. You have done really very good site. Great work, great site! Thank you!

Sorry for offtopic