Posted March 18th, 2011
by admin
Posted by Lee Shirani, director, business product management, Google Commerce
At
Humboldt University in Berlin today, Eric Schmidt announced
Google One Pass, a service that lets publishers set their own prices and terms for their digital content. With Google One Pass, publishers can maintain direct relationships with their customers and give readers access to digital content across websites and mobile apps.
Readers who purchase from a One Pass publisher can access their content on tablets, smartphones and websites using a single sign-on with an email and password. Importantly, the service helps publishers authenticate existing subscribers so that readers don’t have to re-subscribe in order to access their content on new devices.
With Google One Pass, publishers can customize how and when they charge for content while experimenting with different models to see what works best for them—offering subscriptions, metered access, “freemium” content or even single articles for sale from their websites or mobile apps. The service also lets publishers give existing print subscribers free (or discounted) access to digital content. We take care of the rest, including payments technology handled via Google Checkout.
Our goal is to provide an open and flexible platform that furthers our commitment to support publishers, journalism and access to quality content. Like First Click Free, Fast Flip and Living Stories, this is another initiative developed to enable publishers to promote and distribute digital content.
German publishers Axel Springer AG, Focus Online (Tomorrow Focus) and Stern.de joined Eric at Humboldt University today as some of our first Google One Pass partners. Other publishers already signed up include Media General, NouvelObs, Bonnier’s Popular Science, Prisa and Rust Communications.
Google One Pass is currently available for publishers in Canada, France, Germany, Italy, Spain, the U.K. and the U.S. If you’re a publisher in one of these countries and want to learn more, please reach out to the Google One Pass team or submit your information on our website. For interested publishers in other countries, we’d love to hear from you too as we plan to expand to other countries in the coming months.
Read more from Source
Posted March 18th, 2011
by admin
You wouldn’t write your username and passwords on a postcard and mail it for the world to see, so why are you doing it online? Every time you log in to Twitter, Facebook or any other service that uses a plain HTTP connection, that’s essentially what you’re doing.
There is a better way, the secure version of HTTP — HTTPS. That extra “S” in the URL means your connection is secure, and it’s much harder for anyone else to see what you’re doing. But if HTTPS is more secure, why doesn’t the entire web use it?
HTTPS has been around nearly as long as the web, but it’s primarily used by sites that handle money — your bank’s website or shopping carts that capture credit card data. Even many sites that do use HTTPS use it only for the portions of their websites that need it — like shopping carts or account pages.
Web security got a shot in the arm last year when the FireSheep network-sniffing tool made it easy for anyone to detect your login info over insecure networks — your local coffeeshop’s hotspot or public Wi-Fi at the library. That prompted a number of large sites to begin offering encrypted versions of their services on HTTPS connections.
Lately even sites like Twitter (which has almost entirely public data anyway) are nevertheless offering HTTPS connections. You might not mind anyone sniffing and reading your Twitter messages en route to the server, but most people don’t want someone also reading their username and password info. That’s why Twitter recently announced a new option to force HTTPS connections (note that Twitter’s HTTPS option only works with a desktop browser, not the mobile site, which still requires manually entering the HTTPS address).
Google has even announced it will add HTTPS to many of the company’s APIs. Firefox users can go a step further and use the HTTPS Everywhere add-on to force HTTPS connections to several dozen websites that offer HTTPS, but don’t use it by default.
So, with the web clearly moving toward more HTTPS connections, why not just make everything HTTPS?
That’s the question I put to Yves Lafon, one of the resident experts on HTTP(s) at the W3C. There are some practical issues most web developers are probably aware of, such as the high cost of secure certificates, but obviously that’s not as much of an issue with large web services that have millions of dollars.
The real problem, according to Lafon, is that with HTTPS you lose the ability to cache. “Not really an issue when servers and clients are in the same region (meaning continent),” writes Lafon in an e-mail to Webmonkey, “but people in Australia (for example) love when something can be cached and served without a huge response time.”
Lafon also notes that there’s another small performance hit when using HTTPS, since “the SSL initial key exchange adds to the latency.” In other words, a purely security-focused, HTTPS-only web would, with today’s technology, be slower.
For sites that don’t have any reason to encrypt anything — in other words, you never log in, so there’s nothing to protect — the overhead and loss of caching that comes with HTTPS just doesn’t make sense. However, for big sites like Facebook, Google Apps or Twitter, many users might be willing to take the slight performance hit in exchange for a more-secure connection. And the fact that more and more websites are adding support of HTTPS shows that users do value security over speed, so long as the speed difference is minimal.
Another problem with running an HTTPS site is the cost of operations. “Although servers are faster, and implementations of SSL more optimized, it still costs more than doing plain HTTP,” writes Lafon. While less of a concern for smaller sites with little traffic, HTTPS can add up, if your site suddenly becomes popular.
Perhaps the main reason most of us are not using HTTPS to serve our websites is simply that it doesn’t work with virtual hosts. Virtual hosts, which are what the most common cheap web-hosting providers offer, allow the web host to serve multiple websites from the same physical server — hundreds of websites all with the same IP address. That works just fine with regular HTTP connections, but it doesn’t work at all with HTTPS.
There is a way to make virtual hosting and HTTPS work together — the TLS Extensions protocol — but Lafon notes that, so far, it’s only partially implemented. Of course that’s not an issue for big sites, which often have entire server farms behind them. But until that spec — or something similar — is widely used, HTTPS isn’t going to work for small, virtually hosted websites.
In the end there is no real reason the whole web couldn’t use HTTPS. There are practical reasons why it isn’t happening today, but eventually the practical hurdles will fall away. Broadband speeds will improve, which will make caching less of a concern, and improved servers will be further optimized for secure connections.
In the web of the future the main concern won’t just be how fast a site loads, but how well it safeguards you and protects your data once it does load.
Photo: Joffley/Flickr/CC
Read more from source
Posted March 18th, 2011
by admin
Firefox 4, the latest incarnation of Mozilla’s popular web browser, will arrive in final form on Tuesday, March 22. While the final release is good news for Firefox fans, it comes over three months after the initial Firefox 4 release date.
Firefox 4 isn’t the first release to miss its shipping goal, in fact the previous two versions arrived somewhat late as well. To help change that in the future, Mozilla has announced an ambitious plan to revamp Firefox’s development process. Not only will new features arrive faster under this development model, but Mozilla plans to release no less than three major updates this year alone.
The plan is still in the early stages and may change as kinks are worked out, but it currently looks a lot like Google’s development cycle for the Chrome web browser. Like Chrome, Firefox will have several channels, all working simultaneously toward regular releases. A feature will start in what Mozilla is calling the “mozilla-central” channel (nightly builds) and then progress through an experimental channel and a beta channel before arriving in final form. In total each new feature will progress through a 16-week development cycle. Should something break as a feature moves toward the final release, it can be disabled at any point.
Although Chrome helped popularize this development method, it’s also similar to what the W3C is using to add new API features to HTML5 (albeit on a much longer time scale), and it’s how many web-based software projects have long functioned.
Mozilla’s plan also includes something that isn’t easy for Chrome users to do — skip automatic updates. If you subscribe to, for example, the Firefox beta channel, but don’t want to download the latest update, you’ll be able to skip it by disabling the auto-update function.
While Mozilla’s revamped development cycle is still in the early planning stages, it looks to be a big win for both the company and Firefox users. The new development model will help Mozilla push out new features on a more regular basis, without waiting for everything else to be complete as well, and, hopefully, end the frequent delays in Firefox release schedules.
See Also:
Read more from source
Posted March 18th, 2011
by admin
Opera software has released a new developer build of its Opera Desktop web browser with support for Google’s WebP image format. The WebP format is part of Google’s self-imposed mission to make the web faster, and promises smaller images with no visible loss of quality. Currently Google Chrome is the only web browser that supports the WebP format.
The latest development build of Opera now supports WebP as well, though bear in mind that this is an unstable, not-for-everyday-use release. If that doesn’t scare you off you can download the latest version from Opera.
This release of Opera also includes support for linear CSS gradients (using the -o- prefix syntax) and Opera’s new Declarative UI for developers building tools on top of Opera’s extensions platform.
For web developers though, the big news is support for WebP, which should arrive in final form with the release of Opera 11.1 later this year.
See Also:
Read more from source
