Opera Developer News

Trip to Seoul

The folks in W3C Korea organized a HTML5 Asia Day last week. The CJK community gathered to discuss some of the common issues and interest we share. One might wonder why there are only three locale/language-oriented interest group in W3C, namely China, Japan and Korea or collectively called CJK. There are good reasons for it, given that this area constitute a big part of the Internet users and hence also web developer community. Despite the size, there is a lack of participation. CJK is therefore created to encourage more people from this area to participate in W3C.

Another reasoning is that CJK has specific requirement for the Web. W3C have helped shape the web and local knowledge will always be important. Ruby, vertical text, web fonts are amongst the interesting standards that we could offer input from a different perspective.

The HTML5 Chinese Interest Group was officially formed March last year though the W3C mailing list has started since August 2010. So if you count the latter, we have been around for two years. Currently we have close to 700 members and there's a myriad of things we discuss, not just HTML5, from CJK encoding, to HTML5 WG happenings, to even browser support banter.

I'd like to break down some of the things we have done in the Chinese IG.

Translation

We have translated these specifications drafts: Media Queries, Web Storage, Vibration API, DeviceOrientation, cssom-view, HTML5 differences from HTML4, DOM4 (90% completion), File API(80％ completion).

A special shoutout goes to the translators especially Kennyluck, Otakustay, Winter, pingooo, Jinks Zhao, Xiao GuangNiu(牛晓光), Dong Xun Jin(金东勋) and Zhong Jian(中剑).

W3C feedback

We have been able to submit feedbacks to the W3C. So far the IG have submitted four proposals. nine suggestions and seven bug reports. (text-decoration-skip is accepted). The recent css3-flexbox that went into last call，we have made five suggestions and of them two were excepted [1] [2].

Where are the others?

We have seen an increase of Chinese interest in W3C such as the recent Chinese browser session in the AC meeting in France. It will be interesting to see more participation in the HTML5 Chinese IG too.

Even though I work for Opera, our hope is that more companies, especially browser vendors to participate in this group. There are many good people from companies like Google and Firefox. Not forgetting Chinese browser vendors such as UC, Dolphin, Maxthon, 360. It will be good if such voices are heard too.

I was invited to speak to a group of developers at the China Bank of Communications. It was an opportunity to get to know how the IT side of the banking sector works, and to ask them "Why ActiveX?"

First, some background - most if not all Chinese banks use ActiveX for their customer banking, so without ActiveX you can't do online banking in China. Similar issues are happening in South Korea and perhaps other places too. The ActiveX plugin is used to prevent the stealing of passwords by keylogger trojans.

After presenting, the discussion dived right into questions and answers; it was very stimulating and I learned a lot about the perspective of developers working with banks. During the discussion, the thousand dollar question was "If not ActiveX, then what?" I suggested three possible solutions:

• First, if your bank insists on using plugins, then use the NPAPI plugin interface. NPAPI is arguably more secure than ActiveX because it is solely an Internet plugin, while ActiveX can also tinker with your operating system (for example components in Office applications). Opera, Safari and Firefox all support the NPAPI plugin.
• If ActiveX is used only to prevent keyloggers, then another solution might be to only allow users to type their login credentials using a virtual keyboard. This could however be a bane for accessibility.
• The third option is to drop plugins altogether and use a one-time password generator. This crossed my mind with banks in Norway which I am provided with a calculator (I use Nordea Bank). A one-time password calculator will not have the spillover security concerns of ActiveX.

Options above are used to prevent password-snatching while a user is typing in the login credentials - before he or she clicks on the login button which sends the login credentials through a HTTPS secure channel.

On the HTTPS side of things, using Extended Validation (EV) certificates will give bank users better assurance since EV certificates goes through a much more rigorous process before it is given out. Browsers with EV support display more information for EV certificates than for previous SSL certificates. IE8, Firefox, Safari, Google Chrome and Opera support Extended Validation.

During the discussion, I realized that many developers are sympathetic towards standards, including those implementing non-standard ActiveX. I used the word sympathetic because many developers I know are idealist and being idealists they want the world to be a better place. The world is a better place without non-standard code, but the reality is that developers earn their living through customers, and therefore maintaining the existing systems that they already use.

There is more than one way to solve the ActiveX dilemma in the banking industry. It's a legacy issue, for sure, but maybe the real problem is resistance to change?

Note: The PDF version of the presentation can be downloaded here, entitled Web 2.0 and Web Standards.