apk zenonia 5

There has been a lot of fuss about FireSheep, a browser plugin that show how easy it is to intercept packets on the internet, and masquerade as someone else. The idea is nothing new: EtherPeg—which intercepts wifi traffic and shows the JPEGs and other images passing by—is over 10 years old. Annalee Newitz wrote a Wired story on people packet sniffing in coffee shops back in 2004.

The underlying design of the internet means that you don't know who will be able to see any packets you send. If you care about not being snooped on, you need an encrypted connection from your computer to the one serving you at the other end. The best way to do this on the web is to use HTTPS, which all browsers support, and most servers support with configuration changes. It's not perfect, but it's good enough.

However, much of the advice following on from FireSheep was misleading or outright wrong. I saw several articles saying:

• Avoid Open WiFi
  
• Turn on WPA encryption
  
• Use a VPN to tunnel the traffic into a server elsewhere

These techniques may protect for a while against those nearby you in the Café, but by not securing the whole connection, they just change who is able to intercept your communications.

The security model here is the firewall one - the notion that there are trusted networks and untrusted networks, and as long as you're inside a trusted one, you'll be OK. This is an obsolete worldview. When computers were large fixed physical entities with software controlled by a specialist, and networks were wires under their control too, this had some correspondence with reality, but it was always tenuous - others within the firewall could be running compromised machines; outbound connections could still leak data.

If you VPN into a company or service to mask your outbound connections, that endpoint is an attractive point of attack, as it has collected a set of people who think their data needs securing. There's a clear example of this in this NYT article about a hacker who lured his friends to use an FBI VPN to track them down and arrest them.

This worldview connects with two other themes. The US Government is trying to pass a law requiring ISPs to enable your communications to be intercepted. The UK government is also working on legislation on retaining all email and web traffic. Similarly, many companies monitor internet traffic within and leaving their secure networks for legal compliance and employee monitoring. Such mandated backdoors, like the VPN tunnel, become attractive targets for other bad actors - remember the Greek government being spied on through a legally mandated interception backdoor in the phones they used?

This week, I spent a couple of days at the Enterprise 2.0 conference, hearing how open standards like Activity Streams and OpenSocial are being used to bridge separate business information systems both within and between companies, with OAuth used to enforce corporate policy.

This seems anathema to old-line IT managers who assume that they dictate who gets to see what, but the pragmatic realisation that many business people have more powerful and connected computing devices in their pockets as phones than on their desks from corporate IT was in evidence at E2.0 at least.

This brought to mind the great conversation we had with Josh Klein on TummelVision last week, discussing his book Hacking Work - breaking stupid rules for smart results:

one of the most common hacks we found: jumping IT’s firewall and working around their restrictions and tools in open computing environments, then bringing the work back over the firewall and presenting it to bosses as if the corporate tools had actually been used.

Ben Horowitz's article on enterprise sales in TechCrunch today tries to justify corporate practices, even as he recognizes the inversion of the innovation flow.

What this misses is the underlying economic justification for the existence of a corporation in the first place - the economic theories that build on Coase's work saying that firms exist because transaction costs are lower within them than external transactions mediated by the marketplaces. Pettifogging internal purchasing rules should be subject to this test: does the internal transaction cost of approving and purchasing something exceed the value of the thing being purchased?

Reading Ben's explanation of how corporate salespeople help institutions negotiate their own labyrinthine processes, I couldn't help but be reminded of John Hagel's Big Shift model, (also discussed on TummelVision), which continues to show a declining return on assets for corporations.

The challenge we have on the web is to maintain the kinds of open-to-all interoperable standards that empower us to work round these creaking bureaucracies. If we delegate our online identities to a few firms operating proprietary APIs, that they can revoke access to, or decide who can call them for reasons of corporate strategy, the lowered transaction costs suddenly get very high again.

Doc Searls's work on VRM (this week's TummelVision) is all about making sure that we can retain agency over our own information. I expect to discuss this in depth at Defrag next week.

He says:

Your data host’s job is to perform actions on your data. Rather than giving copies of your data out to a thousand companies (the Facebook and Data Portability approach) you host the data and perform actions on it, programmed by those companies who are developing useful social applications.

Which is exactly what an OpenSocial container does - mediate access to personal and friend data for 3rd party applications.

This environment has complete access to the data, and can do anything with it that you want to authorize. The developers provide little applets which run on your data host and provide the functionality. Inside the virtual machine is a Capability-based security environment which precisely controls what the applets can see and do with it.

This maps exactly on to Caja, the capability-based Javascript security model that is being used in OpenSocial.

Your database would store your own personal data, and the data your connections have decided to reveal to you. In addition, you would subscribe to a feed of changes from all friends on their data. This allows applications that just run on your immediate social network to run entirely in the data hosting server.

Again, a good match for OpenSocial's Activity Streams (and don't forget persistent app data on the server).

Currently, everybody is copying your data, just as a matter of course. That’s the default. They would have to work very hard not to keep a copy. In the data hosting model, they would have to work extra hard, and maliciously, and in violation of contract, to make a copy of your data. Changing it from implicit to overt act can make all the difference.

The situation is worse than that; asking people for their logins to other sites is widespread and dangerous. I'd hope Brad would support OAuth as a step along the way to his more secure model - especially combined with the REST APIs that are part of OpenSocial 0.8

If you're interested in these aspects of OpenSocial, do join in the linked mailing lists, and come along to the OpenSocial Summit on May 14th (just down the road from IIW).

When you are browsing the web, you often encounter pages that show different things depending on who you are, such as blog, wikis, webmail or even banking sites. They do this by getting you to log in, and then using a client-side cookie to save you the bother of doing that every time. When you want to give a site access to another one's data (for example when letting Flickr check your Google Contacts for friends), you need to give it a URL to look things up at.

The easy case is public data - then the site can just fetch it, or use a service that caches public data from several places, like the Social Graph API. This is like a normal webpage, which is the same for everyone, returning a HTTP 200 response with the data.

The other common case is where the data is private. OAuth is a great way for you to delegate access to a web service for someone else, which is done by returning an HTTP 401 response with a WWW-Authenticate: OAuth header showing that authentication is needed. If the fetching site sends a valid Authorization header, it can have access to the data.

The tricky case is where there is useful data that can be returned to anyone with a 200, but additional information could be supplied to a caller with authentication (think of this like the social network case, where friends get to see your home phone number and address, but strangers just get your hometown). In this case, returning a 401 would be incorrect,as there is useful data there.

What struck me was that in this case, the server could return a 200, but include a WWW-Authenticate: OAuth header to indicate that more information is available if you authenticate correctly. This seems the minimal change that could support this duality, and much easier than requiring and signalling separate authenticated and unauthenticated endpoints through a HTML-level discovery model, or, worse, adding a new response to HTTP. What I'd like to know from people with deeper HTTP experience than me is whether this is viable, and is it likely to be benign for existing clients — will they choke on a 200 with a WWW-Authenticate header?

HTTP does have a 203 response meaning Non-Authoritative Data, but I suspect returning that is more likely to have side effects.