ENTRIES TAGGED "web"

The Web is eating software

Web technologies have become the default, and are spreading

photo: KF - http://en.wikipedia.org/wiki/User:KF/DetailsA few years ago, venture capitalist Marc Andreessen wrote that “software is eating the world”:

Six decades into the computer revolution, four decades since the invention of the microprocessor, and two decades into the rise of the modern Internet, all of the technology required to transform industries through software finally works and can be widely delivered at global scale.

That may be true, but Andreessen seems to have left out some of his earlier, more Web-centric visions (though perhaps he considers them complete).

Software may be eating the world, but the Web has been “eating software” in a similar sense for as long as the Web has been visible.

On the front end, the browser has grown from being a strange dumb terminal of documents and forms to a full partner. The browser not only provides a window into the world of classic websites, but helps us deal with devices that we can reach over a network. Their interfaces may be invisible or basic on the physical device, but offer much more when accessed through a browser. Web apps, though frequently not as capable as their desktop competition, long ago passed the point where their collaborative possibilities were more valuable than the details they lack.

Read more…

Comments: 2 |

Why polyfills matter

The changing landscape of web platform extensibility

From its nascent days, the growth of the web has been marked by the waxing and waning of technologies, frameworks and ideas. Old ideas and technologies expire and fade away, and new ones arise in their place. Much as the cicada molts and leaves behind an old shell as it moves into adulthood, the web has seen countless ideas come and go as it has evolved.

Relics (and Catalysts) of the Web

Remember XHTML? More specifically, do you remember caring deeply about XHTML? You likely do. Do you still care about XHTML? Chances are, the answer is no. The same goes for Flash, DHTML, HTML Components and countless other buzzwords of the web that once felt so alive and important, and now feel like relics of another time.

Occasionally, however, we collectively stumble upon ideas and technologies that stand the test of time. These are ideas that don’t just evolve with the web–they are often a catalyst for the evolution of the web itself. Ideas like Cascading Style Sheets and XMLHTTPRequest, the vendor hack that spurred the AJAX revolution, are two examples among many.

Read more…

Comment |

What Do We Get for That DRM?

The W3C sells out users without seeming to get anything in return

I had a hard time finding anything to like in Tim Berners-Lee’s meager excuse for the W3C’s new focus on digital rights management (DRM). However, the piece that keeps me shaking my head and wondering is a question he asks but doesn’t answer:

If we, the programmers who design and build Web systems, are going to consider something which could be very onerous in many ways, what can we ask in return?

Yes. What should we ask in return? And what should we expect to get? The W3C appears to have surrendered (or given?) its imprimatur to this work without asking for, well, anything in return. “Considerations to be discussed later” is rarely a powerful diplomatic pose.

Read more…

Comments: 84 |

Securing User Content in the JavaScriptable Web

OSCON 2013 Speaker Series

Recent work by a W3 Working Group plans to expose many powerful cryptographic operations for web applications. Although the planned API adds much needed functionality to JavaScript, it doesn’t address the JavaScript runtime’s terrible security properties. For instance, any script running in the web application has the power to hijack the web app’s content and UX. Just last February a mistake in Facebook’s “like” button brought down millions of web sites. Further, if you are an online service provider wanting to support higher privacy use cases like encrypted chat or web-based PGP email, the trust model is fundamentally broken since you can’t serve cryptographic JavaScript code without making the server a potential attack point.

The security challenges faced by JavaScript are mitigated by Privly, also labeled “the Web Privacy Stack,” by addressing two issues: (1) scoping code to the data, and (2) pre-distributing the code to the clients when possible.

Scoping Code to the Data

Every website has its own navigation structure, layout, and audience, but when you strip away these unique attributes of websites, you are left with data– chats, emails, photos– that can be treated uniformly across all websites. Operations on these data like encryption and signing, can be performed with indifference to their context and their contents.

Privly uses data indifference to create the notion of “Injectable Applications,” which are full web applications that are injected into the context of other web application. Since these applications are scoped to data and not layout, their properties are simplified and usable across the web.

Privly works within browser extensions by scanning web pages for specially formatted hyperlinks. When the extension detects the hyperlink, it “injects” the link into an iframe that is served locally from the browser extension.(footnote 1: This is currently how the Chrome extension performs, but different platforms are at different levels of sophistication. This approach can be universally applied to all platforms and does not necessarily require locally-served JavaScript code. However, without serving the JavaScript code locally, the security properties of the system are lost) Since the injected application is a full web application, the app could potentially support any web-implementable feature, including APIs between the host page and the injected application.

In short, if you scope an application to the data, then the cryptography can be viewed in potentially untrusted contexts.

Pre-Distributing Client Code

Privly creates an ecosystem of apps with known properties because it allows us to reason about security uniformly across the web. However, security is only as strong as the weakest attack point, which is why great care must be taken to appropriately distribute these applications. By packaging a set of applications for integration into browser extensions and mobile apps, the code is not re-loaded from a remote source every time the browser loads a new page.

Requiring the pre-distribution of applications is not normally compatible with the free and open internet. However, pains must be taken to realize the differences between the limited use cases of injected applications, and the general cases supported by web applications in general. Distributing every website to the client before visiting a website is impossible, but distributing a set of general injectable applications is lightweight and perhaps the only way to achieve security within the modern JavaScript runtime.

Requiring users to install an extension before they can view content is likely an impediment for any security system looking to gain users. However, since Privly uses hyperlinks to reference the content, it provides opportunity for a hosted fallback application. Depending on the nature of the injectable application, clicking the hyperlink could either present the same application as normally delivered by the extension, or present a prompt to install the appropriate browser extension.
Read more…

Comment |

Caching Strategies for Improved Web Performance

OSCON 2013 Speaker Series

Caching is the method that most improves response time in web applications (as Steve Souders shows in Cache is King), but in order to make use of it, every layer of your application must be configured for that purpose.

Most applications are initially developed with little or no use of caching and then must be refactored to fulfill performance goals. However, this approach incurs extra development costs that could be saved if response time is taken into consideration in the early stages of the development process.

The methodology that can save your life while you are still developing your application is pretty straightforward: keep caching in mind whenever handling data in your system. Either web APIs or internal backend data flows need to ask one simple question:

Can I survive if the data seen by the user is not the latest?

Sometimes the answer to this question is ‘no.’ For example, I would be fired very quickly if I built a bank system that showed more money than one consumer’s account really has. On the other hand, if the system interacts with general data services like social networks, news, weather, car traffic, etc., there is less need to ensure the latest piece of information is immediately shown to the user.

Of course, the latest data needs to eventually get to the user. Data cannot be too old or you risk confusing the user, but configuring a short expiration time (let’s say 5-10 minutes or less) for dynamic data that can support it can significantly improve the response time experience. That is called temporal consistency and it is crucial for having a successful caching strategy in place.

Nowadays, web applications are based on mashing up several web services coming from different sources. The best way to tackle different response times as well as data designs is to temporally cache those elements across all system layers. It is also applicable to data coming from your own system if the information needs to travel from one part of the world to another in several hops. If information is not critical, consider caching it at any intermediate stage and reuse when it is needed. Caching in the backend can avoid half of a trip. Even better would be to cache at the target device or a CDN system that can dispose of the full data trip or reduce it to only the last mile as an easy way to enhance performance.
Read more…

Comments: 4 |

The Appeal of the Lift Web Framework

The extreme end of weird (as far as web frameworks go)

Lift is one of the better-known web frameworks for Scala. Version 2.5 has just been released, so it seems like a good time to show features of Lift that I particularly like.

Lift is different from other web frameworks (in fact, I labeled it at the extreme end of weird in the first presentation I gave about it), but people who get into Lift seem to love the approach it takes. It’s productive and enjoyable, which goes well with Scala.

I’ll keep this post short. Just two things:

Transforms

You might be familiar with an MVC approach to the Web, where you have code that forwards to a view, and in that view you maybe use a little bit of mark-up to loop or display values. That’s not how it goes in Lift.

Instead, you start with the view first, and use HTML5 attributes to mark the parts of the view that need transforming. Here’s an example:

That’s valid HTML5. You can view it in your browser, or edit it in Adobe Fireworks, or whatever tool you want. The only part of it that looks a little strange is the data-lift attribute. What that’s doing is naming a Lift snippet, and a snippet is just a class. It might look like this:

What’s going on here? We’re using a nifty DSL in Lift to transform the <p> tag so that it contains the content we want. We’re saying…

Read more…

Comments: 3 |

JavaScript Flexibility: Fun, But Use with Care

JavaScript is dynamically typed

When you begin programming in JavaScript, you’ll need to use variables. A variable is just a bit of storage to hold a value. Just about every line of code you write will use a variable of one kind or another, so it’s a good idea to get familiar with the kinds of things you can put in variables, and how you can use them. Now, if you’re coming from another programming language, like Java, you might be surprised to see how loose JavaScript is about variables and their type. JavaScript doesn’t care if your variable starts out with a string value, and ends up being a number: JavaScript’s dynamically typed.

In this installment of Head First JavaScript Programming Teasers, you’ll learn about the basics of variables, how JavaScript is dynamically typed, and why it’s a good idea to stick with one type for your variables.

Comment |

JavaScript Makes Browsers Behave

Start adding functionality to your HTML and CSS with JavaScript

If you know HTML and CSS, you’re ready to begin learning JavaScript. But you might be surprised, because JavaScript looks quite different from both HTML and CSS. That’s because JavaScript is a language for computation. Unlike HTML, which is for marking up content to add meaning and structure to that content, and CSS, which is a set of declarative rules for adding style to selected elements, JavaScript is for describing computation: it’s a language for describing how things get done.

A JavaScript program consists of a series of statements, each of which does a little bit of computation. A statement might store some data in a variable, or modify data with an expression, or make a decision about what to do based on the value of a variable, or even tell the browser to do something, like pop up an alert.

Want to know more? In part four of Head First JavaScript Programming Teasers, Eric shows you how JavaScript is different from HTML and CSS, and why. He also steps you through a simple example of JavaScript code, so you can get a taste of how it works.

Comment |

Cutting Your Programming Teeth on JavaScript

Why it's a great first programming language

JavaScript is a bit different from other programming languages. How? Well, JavaScript runs in an environment, and that’s usually the browser. So when you learn JavaScript, you’ll learn both the language basics, as well as how to use JavaScript in the browser to do things like interact with the page, add and remove elements, draw graphics, or store data locally in the browser.

Another way that JavaScript is a bit different is that it’s so easy to get started with: all you need is a basic text editor and a browser, and you’re ready to go. This also makes JavaScript a great first language. For instance, the fact that you can run JavaScript in the browser means you have a built-in, easy way to see your results, and you can create and interact with a web page interface, without having to write a huge amount of code.

We’re designing Head First JavaScript Programming so that you can learn JavaScript, from scratch, even if you’ve never programmed before. All you need is just some background in HTML and CSS. If that’s where you’re coming from, and you’re itching to learn how to program, check out part three of Head First JavaScript Programming Teasers, where we step you through what makes JavaScript unique, and why it’s a great first programming language.

Comments: 2 |

How you can stop trashing PHP code

Design patterns for PHP

William Sanders (@williebegoode) is a Professor of Interactive Information Technology at the University of Hartford and author of over 40 technical books! His latest book with us is Learning PHP Design Patterns. We recently sat down to talk about design patterns and how they can help create reusable code and save you valuable time. You can also check out more from Bill at his website.

  • Why use design patterns for PHP? [Discussed at the 0:28 mark.]
  • Big programs and lots of code can become unwieldy [Discussed at the 2:06 mark.]
  • Mobile devices and PHP design patterns [Discussed at the 5:30 mark.]
  • Bill talks common design patterns and how they help [Discussed at the 7:25 mark.]
  • How to start using design patterns with PHP [Discussed at the 10:15 mark.]

You can view the entire interview in the following video:

Related:

Comments: 3 |