| CP's profileRandom OracleBlogLists |  Tools  Help |
|
|
September 19 Moving to WordPressThis blog will be continued at a new location hosted by WordPress: http://randomoracle.wordpress.com/ cemp September 05 Opting out of pre-screened cardsIt is not often that one encounters good news on the junk snail-mail front. Credit card companies send large amounts of mail, blanketing mail boxes with pre-approved credit card offers as part of aggressive "customer acquisition" campaigns. Aside from wasting paper, this practice provides would-be identity thiefs with great wealth of material. Typically these letters can not be discarded, they have to be shredded. (For extra caution, using a cross-cut shredder as strip shredders are not particularly effective as the US learned during the Iranian embassy occupation. There is even a DoD standard for the maximum allowable size of the confetti after the blades are done grinding.) Increasingly the offers even provide web-approval options, with authorization codes printed on the page. There was always an opt-out option for these mailings, accessible via phone at 1-888-5-OPT-OUT as well as on the web at OptoutPrescreen, a fancy named website that is run by an alliance of the 3 major credit reporting bureaus: Equifax, Experian and TransUnion. This process is great for user choice, but a privacy advocate might ask why it is opt-out in the first place, instead of opt-in where the default assumption is that customers are interested in receiving these offers. There is also the quirk that a temporary 5-year opt-out can be accomplished on the web, but permanent opt-out requires printing and mailing the form-- guaranteed to steer most visitors to the five-year option because of the added inconvenience. All opt-out options involve providing social security number, which may give users another reason for pause. Granted this process has been in existence for some time. good news is that recent crop of prescreened offers are now advertising the opt-out option, which solves the greatest problem: consumers are not aware that they can opt-out, instead of making confetti out of junk mail regularly. cemp August 25 Search engine privacy (conclusion)In concluding this series, it is time to revisit a question we have glossed over: to what extent can the privacy features built into a web browser help improve privacy on the web. To recap, previous threeposts discussed HTTP state management (glorified phrase for "cookies"), cookie management functionality built into mainstream browsers and one way to utilize that functionality to limit lifetime of cookies. Now for the caveat emptor. 1.Even when search engine cookies are downgraded, other unique identifiers may exist which are consistent across multiple sessions. These are associated with services that require authentication, such as email, which exist in the same domainas the search engine. Given that 99% of authentication the web uses cookies, itis almost guaranteed that cookies are written after signing in. These cookies may be visible to the search engine, providing an independent unique ID that remains constant over time. This brings up a recommendation made by EFF's Seth Schoen, about not logging into search engine services when searching. 2.Cookies are not the only way to uniquely identify users, even though it is the "official" state management system in HTTP. There are a lot of moving pieces involved in web browsing and any one of them can create opportunities for tracking. Several well-known tricks exist to use the browser cache, history or other client-state to correlate requests over time as belonging to the same user. 3. Even if the application layer itself could be purged of all unique identifiers, there is a fundamental problem in the networking layer. Fundamental design of the Internet requires that two parties communicating know each other's address in the network, known as the IP address, even when the communication is passing through many hops along the way. (This is far from being an absolute engineering requirement. Routing could still work if every node along the path remembered the previous neighbour only, without knowing about upstream nodes.) IP address is at first blush a meaningless identifier like 65.54.153.237, which corresponds to spaces.live.com, but the combination of IP address and timestamp is often uniquely identifying. Looking in from the outside, it is impossible to know whether this information is used to correlate requests beyond what is possible with cookies alone. cemp August 16 Data mining: beer, diapers and mythsTaking a break from discussion of privacy features in standard web browsers, here is a detour into data mining land. This newsletter from 2002 discusses the origins of the story that some large retailer discovered using data-mining that people who buy diapers are very likely to buy beer as part of the same purchase. The story is often recounted in different contexts and tweaked to serve different agendas. (Depending on the speaker, this anecdote could be a tribute to the power of data mining, the unexpected and far-from-intuitive patterns hiding in consumer shopping behavior or another sign of privacy under attack from increased computing power.) From what Daniel Power concludes, the true story is not quite as dramatic. It is traced to early 1990s and Osco Drugs (still operating in the Midwest) which contracted Teradata to examine customer purchases and identify patterns. During this study, one suprise the team uncovered was "between 5:00 and 7:00 p.m. [...] consumers bought beer and diapers." Contrary to most renditions of the story, the store did not change the location of these items to encourage impulse purchases. cemp August 14 Search engine privacy and cookie settings (part III)The last posting discussed the idea of downgrading cookies and how it balances privacy with functionality. Next step is to configure a web browser to use this feature. In Firefox this is easy: Tools --> Options, privacy tab and selecting "keep cookies for session only" applies the setting to all websites. Alternatively the site specific settings can be used to specify that cookies from search engines are bounded in lifetime by the session itself. This latter targetted fix can be necessary. Converting all cookies into session cookies does not break functionality as long as the browser is open. In other words within one session, everything appears normal. But long term site customizations and "remember me" type behavior will not work correctly. In Internet Explorer, activating the downgrade functionality is more difficult. IE does not expose user-interface to select this option, even though some of the built in settings use it based on the P3P policy associated with the cookie. Instead a custom XML policy must be imported, using Tools --> Options menu item, selecting Privacy tab and clicking "Import" button to choose a file on the local computer. XML language for the cookie settings is specified on this MSDN page. A quick web search turned up no ready-mode policy to downgrade all cookies, which suggests that creating this for reference may be useful. (Stay tuned for an update to this problem on RandomOracle.) Before moving on to the question of just how much privacy is gained this way, a few words on the technical details. You might be wondering why IE6 uses the shorter of the session lifetime and actual expiration. The reason was to make the downgrade feature more transparent to websites, in order to help compatibility. Good way to view this problem is asking whether a website can detect that a client has downgraded a persistent cookie that website attempted to set. Why is this question interesting? Because if we can answer "no" then we can be confident that downgrading will not have any impact on functionality; a website which can not detect this choice can not experience any adverse effects on functionality. For reference, detecting that a cookie has been rejected is trivial: in fact many websites will verify whether cookies are enabled by attempting to set one and check if it is being replayed. Some websites will not allow users to proceed if that step fails. By contrast, detecting a downgraded cookie in IE6 is nearly impossible during that session: a persistent cookie that was accepted will be replayed, and so will a persistent cookie which got downgraded. Observing the replay, it is not possible for the site to deduce which one happened on the client side. This is precisely the transparency required to guarantee compatibility. But using the Firefox implementation can create one difference that allows distinguishing the outcomes: the lifetime of a short-lived persistent cookie will be extended for the session. Imagine setting a persistent cookie that was only good for 10 seconds-- if this cookie is being replayed after 10 seconds, the website can conclude it has been converted to a session cookie. Caveat emptor: depending on implementation, there are limits on this compatibility guarantee. For example a website that wanted to check if a cookie got downgraded by IE could force a download in a new session. (Challenge: how?) This is more a limitation of the implementation; sharing downgraded cookies and reference-counting them by each session would solve the problem. cemp August 13 Search engine privacy and cookies (part II)Both IE and Firefox allow users to disable cookies selectively based on the website. For Internet Explorer versions 6 and above, this functionality is exposed via Tools --> Options menu, under the Privacy tab. Clicking on "Sites" button brings up a new dialog box where you can view and edit the cookie policy for each site. One subtlety that may not be obvious in this UI is that the sitenames listed are in fact wildcards. For example adding "foo.com" to the block list in fact blocks all subdomains such "bar.foo.com." Firefox supports similar behavior in its own privacy tab, also accessed from the Tools --> Options menu. Under the Privacy tab, there is a button called "Exceptions" which defines site-specific rules. One difference is that Firefox UI distinguishes betweenblocking an entire site including all subdomains (as in *.foo.com) and blocking only the top-level DNS name. In principle one can add the search engine websites into the block list to disable cookies inside limited scope, without impacting functionality of other sites. That is a crude solution because these cookies are typically set in the secondary domain, which means that other services offered in other subdomains will also stop functioning. This is where a useful feature introduced first in IE6 comes in handy. Full disclosure: this blogger wrote most of the privacy and cookie management code in IE6. It is called "downgrading." In order to explain why it is useful for privacy, we have to revisit the two types of cookies. First type are persistent meaning that the cookie has a precise expiration date. This cookie is replayed until that time is reached, which can be-- and often is-- years into the future. The second type is a session cookie, which is discarded when the web browsing session ends. (Unfortunately the notion of a "session" is vague and dependent on the application. For example, when there are multiple windows open they be part of the same session or different sessions.) Downgrading a persistent cookie means that it will be discarded either when the expiration time is reached or when the session ends, whichever occurs first. This second part is a bit of a technicality which makes the feature more effective than simply converting it into a session cookie. Incidentally it is also where IE and Firefox differ: the "allow for session" feature in Firefox only implements the first part. Downgrading cookies is a middle-ground between functionality and privacy. Temporary identification by replaying cookies is required to get any functionality out of the web. Continuing to replay the same cookie over a period of time allows that site to build a comprehensive profile by correlating different requests and associating them with the same user. The solution is to accept and replay cookies but only for limited time; after that "short-time" passes the cookie is discarded and the user is back to square, "unidentified" as far as the website is concerned. (A disclaimer is in order here: strictly speaking, there are ways beyond cookies to identify users, but they are less reliable and far less common.) Length of a session turns out to be a natural way to define that time window. (continued) cemp August 10 Search engine privacy in the wake of AOL (part I)The disclosure of search query data for 650K users from AOL serves as a wake-up call for the privacy community. Original copy has been taken down from the official AOL site, but the disclosed data is now available online for others to search. In principle the data is anonymized, in the sense that users identified by a numeric ID instead of their real subscriber identity. That is no consolation-- often times the query stream itself is sufficient to give clues to the identity of the user, as Declan's original CNet article points out by looking at the history of all search terms typed in by one user. Once again this proves the difficulty of pseudonymizing data. When enough secondary data is attached to a seemingly-random pseudonym-- as the AOL user ID appears to be in this case-- the result is far from privacy enhancing. What about users that only issued a handful of queries, not enough to create a uniquely identifying profile? Their prospects are better for sure, but even their privacy is not completely protected if AOL can translate user ID back into a real-world subscriber identity. Even having the combination of IP address + timestamp for one of those queries is enough. Those 2 pieces of information are sufficient for an ISP to identify the subscriber if he/she is using a computer at home from with a network connection associated with their name. That will be the case for the majority of homes with a dial-up or broadband connection. And this is a good thing for accountability, because it allows law enforcement to map online identities back to individuals: knowing an IP address and associated time when a request, such as search query, from that IP address is observed, they can subpoena the ISP for information about that user. On the other hand it is bad news for privacy, because seach engines colluding with ISPs can accomplish the same objective for commercial motives for less admirable than law enforcement. Putting aside such conspiracy theories, unless the search engine is the ISP of course as with the AOL case, there are simple steps users can take to reduce the amount of information available to search engines. Emphasis on simple: that excludes installing Tor, using anonymizing proxies, wearing tinfoil hat (this MIT page discusses effective designs) etc. Tweaking browser settings can be that first step that works on every PC and does not require expending significant resources. As expected cookies are the culprit: they allow search engines to recognize users across different sessions. When a new unidentified user arrives at a search engine, the website writes a unique identifier into a cookie-- similar to the identifiers which appear in the AOL data set. On subsequent search queries, the web browser announced that ID to the search engine, allowing the engine to deduce that the user searching for "aspirin" right now is the same one that searched for "absinthe recipes" yesterday. Cookies have been much maligned by the privacy community but the hostility is often unwarranted. Completely disabling cookie functionality, as some recommend, renders the web largely unusable. Shopping carts at ecommerce merchants would stop working, anything requiring authentication would likely break and all types of website customization would disappear. There are less radical work-arounds which can balance the need for privacy with getting maximum value out of the web. (Continued tomorrow.) cemp DefCon 14 observationsWhat is going on here-- DefCon is back on the strip? After getting booted from virtually every respectable establishment in Las Vegas and being consigned to the Alexis Park near McCarran airport for the past couple of years, DC was hosted at the Riviera this year August 4-6th. According to Jeff Moss the search for a new venue had been going for the past three years, when the conference began running to limitations about space. For the first time attendees could focus on listening to the talks inside air-conditioned hotel space instead of a makeshift tent baking in the desert heat. Prediction: considering how badly and consistently the Alexis Park gets trashed every year, after just one experience the Riviera management will wake up, smell the coffee and say "never again," joining a distinguished line up of other major venues who earlier reached the same remarkable conclusion, namely that an underage crowd of aspiring script-kiddies who can't (legally) gamble or purchase alcohol is not exactly prime audience. Actual observation: very little damage was inflicted. Over 6000+ people attended, counting the BlackHat block which immediately precedes DefCon. This exceeded the number of battery-powered blinking-blue-LED badges designed by Joe Grand. Usual crowding occurred, with some of the rooms filled to capacity and enthusiastic audience members standing outside the door angling for a peek at the slides. In particular this situation happened with the Google/search-engine privacy presentation on Friday, which was remarkably well timed in light of the AOL search-results disclosure that broke on Monday. Only visible glitch was the program starting out 2 hours late on Friday, which in itself is remarkable considering that this is the first year for the organizers at the new location. cemp August 09 Guest wireless access on campusFinally our Redmond campus offers guest wireless access. The 802.11g here is second-to-none but until recently required EAP-TLS authentication. Those X509 certificates were automatically provisioned on domain-joined machines, after logging into the redmond domain from a LAN connection. When the time of expiration approaches, they are automatically renewed. This works very well, provided your machine is joined to the domain. On a laptop that was not joined, it is very difficutl to connect. After trying all types of work arounds-- including running a domain joined virtual machine, which didn't work because the VM did not have control over host wireless card to authenticate-- the solution arrived unexpectedly in the form of IT department providing guest wireless starting in July. Hopping on the network requires getting username/password from the reception but otherwise works reliably. cemp July 24 OpenSSL and FIPSInteresting story unfolding on the open-source front. The cryptographic library OpenSSL made headlines in January when it achieved FIPS compliance. FIPS stands for "Federal Information Processing Standards" and specifies requirements for implementation. Getting FIPS 140 compliance is generally a requirement to compete in government and defense markets. OpenSSL achieved level 2 which is good for use with sensitive but not classified data. Until that point only commercial offerings had achieved FIPS certification, which generally involves submitting code and documentation to third party auditor/testing lab. (Full disclosure: this blogger has worked on the Windows cryptography code base and its successor CNG in Vista) Last week the National Institute for Standards and Technology (NIST) which oversees the FIPS standards revoked the OpenSSL certification. There is a lot of controversy over that apparent back-pedalling (inevitable Slashdot discussion) but one thing certain is it will cause frustration for customers which already deployed the app or used the associated library for building their own applications. (There is no mention of these developments on the official OpenSSL website where users can still access different flavors for download. It is also included in the popular kit cygwin.) According to the article from GNC, the Open Source Software Institute which sponsored the evaluation is likely to continue the efforts. cemp July 22 Mobile computing environments in infancyThe promise of easily roaming your computing environment (applications, settings, data and all) without carrying around expensive hardware is still a long way off from crossing the chasm. Another recent entry into this space is the Bio-Computer-On-a-Stick, available from ThinkGeek. It is a USB based device that combines biometric authentication with a compact Linux distribution. The website for the manufacturer FingerGear has other variants including simple USB drives and the computer-on-a-stick without biometric authentication capability. Individually none of the specs are impressive. Only 512MB of space when most USB flash drives from most manufacturers these days are pushing 4GB limit and under $50/GB cost factor. Powering the device is a Linux 2.6.x kernel with Gnome front-end. Applications include Firefox, Open Office suite (stressing the MSFT Office compatibility), PDF viewer, standard Unix tools such as ssh for remote connectivity and open source instant messaging client GAIM. According to the web page, it can boot directly from USB on most computers, or you can use the included CD to get started. Boot times claimed are less than 40 seconds. Perhaps the most unique feature is largely a distraction: there is an integrated finger-print reader which can be configured to become the gatekeeper for access to the device. The website does not make any mention of tamper-resistance or FIPS compliance. Without taking additional measures to block access to underlying storage, finger-print reader will only stop the casual attacker. Equally controversial will be this security claim from the website: " 
Significantly reduce your exposure to viruses, worms and spyware by running applications from a standalone device."This can be misleading. When the device is plugged into a host PC, it is still very much at the mercy of that PC. Rogue host can still copy everything off the device or feed the device bogus data. That Word document the user was editing, can get corrupted in memory before being saved back into the data segment. In practice this is going to be difficult because the host OS is not used; malware must embed itself in BIOS or perhaps into a hypervisor that takes control before the ordinary boot sequence from the USB drive starts. (Judging by the specs, the OS itself is on write-protected non-flash memory which ensures that at least it can not be tampered with even by untrusted host.) There is also the obvious problem that you can not roam the OS of your choosing-- you are stuck with what is available on the distribution itself. Flexibility this is not. For all these problems, this is still a promising start towards mobile computing made practical. cemp Post-script: ThinkGeek website says they are sold out due to popularity of the item. July 21 Yahoo! Music debuts DRM-free MP3 downloadsSo far legitimate online music services have been trying to compete on features and selection. Yahoo is trying a different approach by trading off DRM restrictions against a premium price. (The only other service which allows users to download unrestricted MP3s is the gray-market AllMyMP3.com website based in Russia, which has been the subject of great controversy recently, with speculation that its existence may imperil Russia's bid to join WTO.) Describing the strategy on the official team blog, one employee puts it very bluntly: As you know, we’ve been publicly trying to convince record labels that they should be selling MP3s for a while now. Our position is simple: DRM doesn’t add any value for the artist, label (who are selling DRM-free music every day — the Compact Disc), or consumer, the only people it adds value to are the technology companies who are interested in locking consumers to a particular technology platform. These are fighting words, considering that the recording industry has pinned its hopes on stronger DRM enforcement as part of its digital distribution strategy. In keeping with the bold nature of the move, the first offering is a "customizable song" where the customer can hope to find his/her name in the lyrics. (Foreign nationals including this blogger and those with less common names are out of luck-- maybe one they will get one of those speech synthesizers to superimpose names into the music.) This costs twice as much as the a la carte pricing of individual songs from mainstream services such as iTunes. It is not clear whether that is supposed to compensate for expected increase in piracy due or to the cost of recoding multiple variants of the lyrics. Changing both of these variables makes it difficult to compare, which may have been intentional: the blog posting itself suggest s that the price correction required for free MP3 puts the market value somewhere between $0.99 and $1.99. One would expect that 2x is a small increase to compensate for increased piracy since each unrestricted MP3 could arguably reach much more than a single additional customer. Considering that the profit margins are massive to start with, any unauthorized copying would require effectively selling one more copy to compensate. Economics suggests that 2x increase corresponds to an expected 100% piracy rate where each MP3 sold on average is made available to one other person who otherwise will have paid for the full DRMed copy. It will be interesting to see how these dynamics play out-- whether Yahoo! cancels the program unceremoniously or succeeds in positioning itself as the legitimate home-brew alternative AllOfMP3.com. cemp July 08 Visualizing a social networkCombining some Perl scripts with the Graphwiz package, here is a visualization of a fragment of MSN Spaces around a colleague on the Windows Live Identity team. cemp Google Checkout launches and eBay promptly bans itMuch awaited Google Checkout went live in the last week of June with much fanfare, some skepticism and a quiet announcement by eBay signalling that the auction giant is serious about protecting its own turf. Good news is that Google is serious in building a platform by attracting both buyers and sellers. The chicken-egg problem for getting traction on a new payment system involves building both a compelling array of ecommerce merchants willing to integrate the system and a compelling size of consumers capable of using the currency. Unless their favorite websites offer the new checkout option, consumers will not bother signing up for one more service, the argument runs. And unless a sizable fraction of potential customers can pay using this new scheme, retailers are not going to invest in supporting one more option. This is a daunting boot-strapping challenge. On the positive side, it is also a virtuous cycle, a positive feedback loop where more customers attract more merchants and they in turn create incentives for other consumers to jump on the bandwagon. Crossing the chasm from no-no to the self-sustaining growth requires artifical incentives, when the payment platform initially subsidizes adoption potentially at a loss. (At least one critic called the strategy predatory pricing in the case of Google.) Incentives are plenty here. The offering launched in collaboration with Citibank is going live with heavy-hitters out of the gate including Buy.Com, Starbucks and uBid, including discount coupons for using GC as the payment option. For merchants Google slighly underprices Mastercard to create an incentive for at least featuring the new offering side-by-side with the conventional payment card solutions. But one critical merchant that Google Checkout is unlikely to win over is eBay. Paypal and eBay enjoyed a symbiotic relationship over the years, with Paypal providing the convenient payment option for peer-to-peer payments for small ticket items listed on the acution website. In a rare blunder, eBay attempted to introduce its own payment currency at one point, only to back pedal after users virtually mutinied. The logical followed and eBay acquired Paypal. PayPal has the first-mover advantage for online payments. It has no serious competition except for risky, niche markets such as online gambling where the company, already under fire from regulators, has been wise not to participate. Question for Google: without the benefit of a "killer application" such as eBay, can the new Checkout service achieve critical mass? cemp July 02 RFID security concerns: scanners everywhere, darkly(Continuing an earlier post on the AmEx Blue cards with RFID chips.) Perhaps the biggest problem with RFID tags is the lack of consent element. Existing forms of identification require affirmative step by the individual before he/she can be identified. It could very old school as taking out a drivers license from your wallet or inserting the bank card into the ATM machine. Because RFID works at a distance-- and the preferred term these days is "contactless card" to emphasize that-- the tag can be read surreptitiously. All that is required is a transceiver operating on the right frequency; by design the tag broadcasts its identity to any source willing to inquire. (Kim Cameron described it as a "beacon" broadcasting identity in an omnidirectional way, as part of this critic of existing identity systems in the influential paper The laws of identity.) That lack of user control is the basis for many of the nightmare scenarios critics of RFID like to spin. Smart bill-boards could select an advertisement based on scanning active RFID tags on objects you are carrying. Retail stores could immediately profile a customer the moment she walks in the door, based on scanning objects they are carrying. This is either a marketing dream or privacy invasion, depending on the point of view. There are also darker predictions of high-tech criminals wondering around with RFID scanner, searching for tags to copy information from. It is not comfort that the intended reading range is a few inches. That is for normal usage, not an adverserial minded world where criminals have motivation to scan the identifier on the tag against the user's own interest. For example the next generation of US passports have RFID chips. The claim that they had a very limited range for reading lead to an interesting showdown at CFP 2005 in Seattle, between the State Department's Frank Moss and ACLU's Barry Steinhardt. Speaking on the same panel, Moss fired the first shot by insisting that the passports could not be read at distances greater than 4 inches. Steinhardt counterd later with a live demonstration showing that it could in fact be read at a distance of about one yard using home-brew electronics. Clearly this is a pure technology race: more advanced readers will achieve greater range, depending on the transmission power. Applying the same logic to credit cards, the question becomes: what prevents unauthorized scanning of information on the card, and cloning it for use in unauthorized purchases? Annalee Newitz has written extensively about the dangers of RFID, including a piece in Wired. The subject is close to her heart, or actually in this case close to her arm-- she has an implanted RFID chip from Verichip. This application is unusual in humans, although it has been standard fare for identifying pets. One driving scenario is controlling access to restricted areas. Instead of carrying cards, typing in codes or staring into a camera for retinal scans, users will wave their arm at the reader in order to unlock the door, this story goes. Newitz's story shows that the cloning risks are very real in this case: with a little help from the subjects interviewed for the article, she was able to clone the RFID tag in her arm. cp Mining social networksThere are plenty of anecdotal stories around job applicants getting rejected based on their pages on MySpace, LiveJournal or Facebook. Call it the open-source background check, which dispenses with the expensive gumshoe investigator in favor of web surfing. (Most of these sites have public access to user pages, only Facebook requires an account or connection to the university in question.) This NewScientist article added a new dimension by suggesting that intelligence agencies have taken an interest in mining social networks. Granted it is a very indirect link, citing funding for a paper that looked at relationships culled from the Friend of A Friend social networking website and compared it against the DBLP directory of computer science publications. The cross-referencing of data from these two sources revealed conflicts of interest in the blind-refereeing process. This is reminiscent of Jeff Jonas's work on NORA or non-obvious relationship awareness. Jonah is the unsung hero working on the side of the casinos in Ben Mezrich's great 2002 book "Bringing Down the House" chronicling the battle of wits between Vegas casinos and MIT students trying to game the system at blackjack. His data mining system has been used to identify suspicious conditions such as a high-roller with the same address as one of the dealers or shell-companies set up by employees to act as vendors to the same company. cp June 12 Google spreadsheets beta24
hours after requesting access to the Google spreadsheets beta, a
message arrived in email with a personalized URL, equivalent to an
invitation to the party. (Does Google show preference to GMail accounts
or users who had participated in betas in the past? Access request
after all went to a Gmail account active since April '04. That account
owes its existence to an unusual event at CFP 2004 conference, when
Nicole Wang an attorney for the company appeared on a panel discussing
the privacy implications of advertising based on fulltext of email
messages. Attempting to placate a very hostile crowd, she invited the
audience to email lawyer@gmail.com to get an invitation and experience
it for themselves. It is not clear if the sentiment of CFP audience
changed but at least this blogger managed to get an early peek.) First
impressions: the spreadsheet application is impressive, if not in
absolute terms as a productivity application then at least as an
example of just how much can be done with Javascript and HTML alone. It
is definitely the opening salvo in what is likely to become a highly
contested race for delivering services. Web browsers have gotten an undeserved reputation for being plain, vanilla-- when other applications are called "smart clients" by contrast to a web browser, the implications are not flattering. Developers have always been looking to Flash, ActiveX, Java etc. for adding that missing power to web pages, at least until recently. With the emergence of AJAX, the promise of DHTML circa 1998 at the height of the browser is finally getting realized. Google did not invent AJAX but played a significant role in taking it mainstream with Gmail first, and later with Google Maps. Google Spreadsheets continues the tradition of pushing the envelope of the what is possible. Among the impressive features: undo/redo capability, basic formatting for cells including font/color/typeface/alignment, uploading Excel documents (as well as downloading the spreadsheet as either CSV or Excel), formulas with basic math functions. User interface is intuitive, surfacing most common functionality in one-click buttons or links. But Spreadsheets also resurrects the trust question raised by Gmail. Documents can be saved online-- in fact the sharing option, which allowstype of communication granting other users permission to view and even edit documents depends on that. This is good news for reliability; there is no worrying about data loss. On the other hand it means that the service in the cloud is trusted with all content. This is already true for email, which is why enterprises operate their own email service-- having confidential documents in a server "out there" is unlikely to work. Home-users are less risk-averse but remote servers remain a black-box for users. Some are comforted by the TOU and privacy policy, others use it only as a starting point for colorful conspiracy theories. Final question is whether webbified versions of productivity applications will ever become competitive with full-fledged productivity applications. At one point Java was also touted as removing the need for client side applications and converting PCs into thin-terminals, which sounded like a throw-back to the 1970s time-sharing era. The free OpenOffice suite already provides some level of interop with Microsoft Office formats. And services exist that allow online replication/sharing of content with other users. On its own, these features are not compelling enough to switch to web-based applications. More importantly, it is not very difficult to make an existing shrink-wrap application available as a service: deploy it on hundreds of machines and allow users to terminal server from any location. (Vista has the RAIL model making this even easier.) cemp June 08 American Express Blue and RFID: here we go againWhen it debuted in 1999, the American Express Blue was positioned as a revolutionary new way for doing online banking. Unlike existing cards on the market, it contained a chip. It was more than a passive magnetic stripe to be scanned at the point-of-sale. Given a compatible card-reader and appropriate software, users could shop online with greater security and convenience. At least that is how the story went. In reality Blue ended up being a good marketing gimmick that ensured AmEx's return to the credit-card business after the struggling Optima line. (AmEx is still primarily known for charge cards, which boast no preset spending limit but require the balance to be paid in full at the end of every bulling cycle. Optima cards allowed users to carry balances, positioned to compete with existing offerings from Visa, MasterCard and Discovery) Predictably, AmEx never got past the chicken-egg adoption problem in spite of giving away free card readers during the trial period: without a critical mass of users, websites were not going to implement a proprietary one-off check out solution and without a critical mass of ecommerce sites accepting the new system, users were not about to change their ways. More importantly the chip itself did not do PKI: it did not contain a digital certificate that could have been used to authenticate the card-owner and sign transactions. If the chip contained a certificate and could integrate with existing protocols such as SSL for web authentication and S/MIME for secure email, it would have enabled an open ecosystem with other vendors developing new applications to take advantage of the capability. (BTW chipped cards are not at all unusual in Europe; in the US the different economics of fraud does not justify all cards and point-of-sale systems to be upgraded. A representative from MasterCard working on anti-fraud made this interesting statement at the 2004 NDSS symposium in San Diego.) In spite of the smart-card being a dud Blue did succeed in the market place by all appearances. It is surprising that the next generation of the card has dispensed with the chip and replaced it with an questionable technology: RFID tag. Owing to bad reputation attached to the label "RFID" the preferred term these days is "contactless cards" but the implications are same: payment information on the card can be read without having to scan the card through a magnetic reader. In fact the website touts this capability where it is called ExpressPay, but you would have to dig through card benefits to discover the link. Convenience comes at a price however, and there are security concerns about adding RFID tags to cards, with echoes of the same problems as the new state department plan to issue RFID Passports. [continued] cemp May 04 CFP2006 first dayQuick impressions from the Computers, Freedom & Privacy 2006 conference, in Washington DC. My colleague Mike Hintze, senior attorney with MSFT, presented on an interesting panel yesterday about federal privacy regulation. He pointed out that current patchwork of state regulation leads to confusion and the lack of consistent assurance in data proteciton is starting to erode customer confidence. New York Times author Eric Lichtblau, winner of the 2006 Pulitzer prize, appeared on a panel yesterday to discuss his experiences reporting on controversial current events. cemp April 19 Ballot stuffing online: script kiddies vs Washington stateWashington state discovers the disruptive power of automated scripts. The salmon and orca whale faced off in a contest to decide the design for quarters in Washington state but the winner was script kiddies who disrupted the voting process. Link to Seattle Times article. Ballot stuffing is not new. (Just ask the baseball fans about the All Star team selection.) The article discusses mitigations around limiting number of votes from a single IP address. Problem is that IP addresses do not correlate one-to-one with individual users. Proxies can act on behalf of multiple PCs and sometimes a single shared PC in a library or school could be legitimately used to cast multiple votes. And botnets distributed across hundreds of machine would still have an advantage. Part of the problem is lack of good identity system to identify voters. Online identities detached from any real world connection are fragile; users can register for as many as necessary. In the absence of a single-voter unique identity guarantee, only ad hoc rate limitations work. This would have been a good opportunity to use a CAPTCHA or HIP to rule out automated scripts. It is the same technology used to combat blog-comment spam here on MSN Spaces and on Blogger. cemp |
|
|
