homdigitalis

Como remover contas das redes sociais

Publicado em 19/06/201025/10/2010 por homdigitalis

Smashing Magazine – we smash you with the information that will make your life easier. really.

We all have an increasing number of sites and online services we’re members of, and sometimes it all gets a little overwhelming. At times, we just need to delete our memberships to some sites, either in an effort to simplify our lives or just because we’ve grown tired of a particular site or service.

What we often don’t realize when signing up for all these accounts, though, is how difficult it can be to permanently delete our accounts when we’ve had enough. Some require complicated, multi-step processes that can stretch over the course of days (or weeks). Others take less time, but still require multiple steps by the user.

Below we’ll take a look at the account deletion processes of popular websites and services, and how easy or difficult they make it. Then we’ll discuss why sites make things so complicated, and some things to consider when designing your own deletion policies.

[Offtopic: by the way, did you know that there is a Smashing eBook Series? Book #1 is Professional Web Design, 242 pages for just $9,90.]

Facebook

Difficulty (on a scale of 1-5, 5 being hardest): 5

Deleting a Facebook account is a bit more complicated than many other services. There are two options for getting rid of your FB account, one that’s permanent and complete, and one that lets you change your mind later.

If you just want to shut down your account for a little while, with the option to reactivate it later, you can deactivate your account. This is simple: just go into your account settings and click on the “deactivate account” link. This immediately makes your account invisible to everyone else on Facebook. If you decide at a later date that you want to reactivate your account, it’s as simple as reactivating.

If you’re looking for something a little more permanent, though, you’ll need to submit a request to Facebook. The tricky thing here, though, is that they don’t immediately delete your account, and if at any time before it’s permanently deleted you log in or otherwise interact with Facebook, your deletion request will be canceled. For that reason, it’s a good idea to go around to any computers or devices (like your mobile phone) that you access your account through and log out (deleting saved passwords is also a good idea to prevent an accidental login).

Then you can use the form found here to request deletion. Remember not to log into your account at any point after that. There doesn’t seem to be any official notice on how long it takes, but unofficial reports say 14 days. To be on the safe side, you may want to wait a month or more before attempting to login to confirm your account has been deleted.

More information on deleting your Facebook account can be found in their FAQs.

Twitter

Difficulty: 2

In contrast to deleting a Facebook account, deleting a Twitter account is relatively easy. All you need to do is go into your account settings and click on the “Deactivate my account” link at the bottom of the page. This is a permanent deactivation, though it can take up to a month for your account and information to disappear entirely from their system.

One word of warning, though: if you think you might want to use your email address, username or phone number on Twitter in the future, make sure that you change them prior to deactivating your account. Whether these things are permanently blocked from Twitter in the future or only temporarily isn’t specified, but it’s a good idea to change them anyway.

You can find more information on deleting your Twitter account here.

MySpace

Difficulty: 4

Deleting a MySpace account is a bit convoluted, but doable. You’ll need to login to your account and then go to the “My Account” link, and then select “Account”. Scroll until you see the “Account Cancellation” section and click on “Cancel Account”. This is where it gets a little bit complicated. MySpace will then send you an email with instructions for completing your account cancellation. Except the email doesn’t come right away, and can take a couple of days to show up. Once you get the email, it asks you for confirmation again that you want to delete your account, but then deletes it immediately.

All of the above works just fine, as long as you still have access to the email address you signed up with. But as so often happens when we finally decide to clean up our online accounts, some of them may be associated with outdated email or other accounts. In that case, there are a few alternatives listed by MySpace. The first one is to edit your profile and replace everything in your “About Me” box with “REMOVE PROFILE” and then contact MySpace and tell them to delete your profile (including your friend ID or URL). If that doesn’t work (say, if you can’t login to your account at all), you can just contact MySpace and ask them to delete the profile. How quickly they actually do so isn’t specified.

Official instructions for deleting your account can be found here.

Difficulty: 3

LinkedIn makes it quite easy to delete your account, once you know where to look. Click on “Settings” in the upper-right of the screen once you’re logged into your account, and then select “Close Your Account” under “Personal Information”. You’ll then be prompted for the reason you’re closing your account, and once confirmed, your account will be deleted.

As far as social networking sites go, LinkedIn probably has the most straight-forward account closure process. More details can be found here.

Google

Difficulty: 3

Considering how pervasive Google is in our digital existence, you’d think deleting your Google account might be incredibly complicated. After all, many of us use dozens of Google services, and you’d think each one would require separate deletion.

For the most part, deleting your entire Google account is easy. There are only a few services that require special consideration. Of course, with the exception of a couple of services, there’s no way to delete individual services completely from your Google account. For example, with Analytics, you can delete each individual site you’re tracking, but not the Analytics account itself.

To delete your main Google account, login through the Google Accounts homepage. Then click on “Edit” next to “My Products”. From that page, you can delete certain services (Orkut and Web History), as well as delete your entire account by clicking on “Clear account and delete all services and info associated with it”. This will take you to a form where you’ll need to confirm each of the services you’ll be deleting. If you linked your Google account to an existing YouTube account, you’ll need to delete that account separately.

Then you’ll need to confirm your password, and check that you do, indeed, want to close your account, and that you know you’re still responsible for any pending financial transactions associated with your account. Then confirm, and your account will be deleted.

Certain services, including Google Alerts, Groups, and Docs, aren’t automatically deleted in this way. To unsubscribe from alerts, you’ll need to refer back to your original Alerts email (or from any Alerts email you’ve since received) and click the ‘unsubscribe’-link there. For Groups, you’ll also need to unsubscribe from each group.

Google Docs leaves shared documents and presentations available to collaborators and viewers. Spreadsheets, on the other hand, aren’t available to collaborators or viewers once you’ve deleted your account (so have a collaborator create a copy of the spreadsheet prior to deleting your account). With shared documents and presentations, you’ll want to reassign ownership to another user before deleting your account.

Full details on deleting your Google account can be found on the Google’s Help page “Deleting: Your Google Account”.

Ebay

Difficulty: 3

Ebay makes it fairly easy to close your account, though they do impose a waiting period. All you need to do is make sure your account has a zero balance, and then click the link to request your account be closed on this page.

One caveat: if you think you might want to use your email address for another Ebay account in the future, make sure that you change it prior to deleting your account. Email addresses and user IDs cannot be reused in the future. Once the waiting period has ended, your account will be deleted and your feedback ratings and other information will no longer be visible. Whether that information is permanently deleted or stored on a server somewhere ad infinitum isn’t specified.

Wikipedia

Difficulty: Impossible

Wikipedia is one of the few websites out there that doesn’t allow you to delete your account. That’s right, once you have a Wikipedia account, you have it forever. There is some hope, though, if you really don’t want to be associated with it any longer.

In most cases, accounts can be renamed and your user page can be deleted, along with (in some cases) your user talk pages. While this doesn’t erase your tracks entirely, it does effectively let you vanish from the site.

Wikipedia’s reasoning behind this is that all contributions have to be assigned to someone. They can’t have anonymous or orphaned contributions, or it would potentially ruin the crowdsourced and open nature of the site.

Flickr/Yahoo!

Difficulty: 2

Deleting your account on Flickr is relatively easy. Once you’ve logged into your account, go to your account settings and click on the “Personal Information” tab. From there, click the link “Delete your Flickr account”. A warning screen will come up that informs you that the deletion is permanent, and that all of your photos and videos will be deleted.

Deleting your entire Yahoo! account is a separate step. Log into your account and then go to the account deletion page. This page explains what happens when you delete your account. User information is kept on Yahoo!’s active servers for 90 days after the deletion has been requested, and may persist in backups beyond that. Once you’ve read the information on the page, you have to enter your password, a captcha code and then confirm that you want to delete your account. One thing to remember: if you’ve signed up for any Yahoo! premium services, you may still be billed for those after your account has been terminated, so make sure you cancel those premium services before you delete your account.

Windows Live

Difficulty: 2

Closing your Windows Live account is actually surprisingly easy. There’s only a problem if you’re using that account to access other websites. If so, you’ll need to go to each website where you’re using your Windows Live login credentials and delete your accounts there prior to deleting the Live account itself. If you don’t, you won’t be able to delete those accounts (or do anything with them) once your Live ID is deactivated.

Now, once you’ve verified that all your accounts linked to your Live ID have been closed, all you need to do is go to your Windows Live account and click on the “Close your account” link at the bottom under “Other Options”. This will bring up a page that tells you what happens when your account is closed. This includes that your registered information will be permanently deleted, that some information might not be deleted (refer to their privacy statement for details on that), and that if you have associated children’s accounts with that Live ID, they will also be deactivated. To finish the deletion process, you have to type in your password and click “Yes”.

There are reports that at this point you may be told there is a Microsoft email account associated with your account, and that your account cannot be closed. From there, you just need to click on “Close your Microsoft account” and then “Close my account”.

Stumbleupon

Difficulty: 1

Stumbleupon is one of the easiest web services to delete your account from. Just go to their delete account page, enter your user ID/nickname and password, and click on “Delete Account”. That’s it! Account deletions are permanent, so make sure you really want to delete your account before clicking that “Delete Account” button.

WordPress.com

Difficulty: Impossible

WordPress.com doesn’t allow you to delete your account. Instead, they recommend you simply leave the account inactive. If you’re worried about the information you’ve uploaded to your WordPress.com account, remember you can always delete the information contained in the account (or replace it with false information).

Start by deleting your blogs. To do that, go to Tools and then “Delete Site”. There’s an email confirmation step required. You may want to run an export of your site’s content first, just so you have a backup in case you ever want to repost or reuse any of it (or just for posterity). After that, you can replace your email address and other identifying information with alternative information. More information can be found on this page and this one.

Amazon

Difficulty: 3

Closing your Amazon account requires you to contact their customer service department to request the account to be closed. This can only be done if you have no pending transactions, so make sure you’ve either received or cancelled all recent orders.

The email to customer service has to be sent from the email-address associated with your account. Other than that, they don’t give any indication of either how long it might take to delete the account or if there are additional confirmation steps involved.

YouTube

Difficulty: 3

If your YouTube account was set up with your Google account login credentials (as in, you used your Google account to sign up for your YouTube account), it’s automatically deleted when you delete your Google account. But if you set it up separately from your Google account (or linked the accounts together after they were both set up, or if you want to keep your Google account), you’ll need to delete it separately. One thing to note is that deleting your account does not delete your videos or channel, just your profile information. You’ll need to delete those prior to deleting your account.

The deletion process is pretty straightforward, though it does have a few more steps than are really necessary. Log in to your account and then go to “Manage” from the drop-down menu under your user name. Then click on “Manage Account” and then “Delete Account”. It will then ask you why you want to delete your account. Fill that in and then click the “Delete Account” button. YouTube then brings up a window that reminds you that your videos will not be deleted, only your profile. If you’ve deleted your videos and channel (or opted not to), then click on “Delete Account” one more time. You then have to confirm one more time. After that, try logging into your account again to make sure it’s been deleted.

PayPal

Difficulty: 1

Closing a PayPal account is pretty simple. Just log in to your account, and then click on your “Profile” link. From there, click on the “Close Account” link in the “Account Information” column. You’ll be prompted to continue from there and then you’ll need to click the “Close Account” button.

You’ll want to make sure your account is current and that there are no pending transactions, and of course you’ll want to transfer the positive balance to your bank account. There are reports that if you delete your PayPal account, it’s more difficult to get another one in the future (as in, they require more information of you). Whether this is true or not is unconfirmed.

Why’s It So Complicated?

In the case of every service mentioned above, properly deleting your account is a multi-step process. Some sites are even more difficult. It’s not a technical issue, obviously, as programming a functionality to let users delete their own accounts is something most competent developers could do before breakfast.

So why do some sites make it so complicated? The answer is user retention. They don’t want you to delete your account. The hope is that if you have the account, you’ll use it at least occasionally, if for no other reason than curiosity about things you might have missed when you weren’t logged in. As soon as you delete that account, though, it’s an out-of-site-out-of-mind kind of thing. You’re less likely to sign up for another account if you decided you could live without it once.

Account Deletion Remorse

This is one very valid reason to make it more complicated to delete an account: deletion remorse. It’s not uncommon for a user to have a bad day, get angry about something going on within a social network, and decide they’ve had enough and are getting rid of their account.

Of course, what often happens is that a day or two later they realize how much they loved using that social network, and they wish they could get their account back. With account deletion policies like those of Facebook (on which I’ve witnessed such account deletion remorse first-hand), users can just reactivate their account, and have all of their old friends and information right there. On sites with more immediate deletion policies, that user would likely have to start over entirely.

Should You Use Complicated Account Deletion Processes?

Considering how many major sites out there have complex methods for deleting accounts, should this be industry standard? Should all sites employ these methods to help retain users who can’t be bothered to follow a multi-step process? Probably not.

There are a few things to consider when deciding whether you want to make it complicated for a user to delete their account. First of all, if your deletion process is going to be handled by customer service representatives, do you have the manpower to do so? If you suddenly have a thousand members who want to delete their accounts, do you have the resources to handle that?

Do you expect users to regularly delete their accounts just to sign up for a new one a week later? If it’s complicated to delete their account, they may never sign up for another one, not wanting to go through the process again.

Inactive accounts can also eat up your system resources. Server space can become an issue, especially on very popular sites (or sites with very low budgets). Plus, it makes maintenance and backups more intensive, since there’s more data to deal with. Making it easier for people to delete their accounts if they’re not using your service can help relieve that load.

The level of complexity for the account deletion process is something that needs to be considered on a site-by-site basis. In general, the easier the process is, the better; however, it is important to make sure that users may be having a bad day and make a mistake by closing an account and so they will be happy about getting the account back a couple of days after it was closed.

Making the process way too difficult and time-consuming will turn annoyed customers in angry ones, the ones who will be very likely to spread negative word out there, while annoyed users would probably just close the account and move on, and even maybe come back to the service later. In either case, one way to minimize your worries about it, though, is to keep your users happy and conduct your site’s business in a transparent and open way.

(vf)

Menu Contextual

Publicado em 19/06/201025/10/2010 por homdigitalis

Google Chrome com sincronismos de extensões ConkyWizard – Configure o conky facilmente

Your Menu 1.0 – Melhore os seus menus de contexto

Criado por Vítor M. em 18 de Junho de 2010 | 12 comentários

Já expressei algumas vezes a minha admiração e predilecção pelo menu de contexto. Uma função que melhora de sobremaneira a usabilidade dentro do Windows. Gosto de tal forma que, mal comecei a mexer no MAC OS X, tive de ligar lá esta função, que vem nativamente desligada. Não sei trabalhar sem o menu de contexto, ainda mais quando o temos optimizado com o nosso método de trabalho. Para simplificar deixo uma sugestão : Your Menu.

Esta aplicação é “inofensiva” mas muito interessante. Como não precisa de a instalar, pode simplesmente usar para criar as entradas de registo. Tudo limpo seguro e rápido.

Depois de descarregar a ferramenta, abra o zip e corra a aplicação. Verá que se abre uma janela, como pode ver em cima, onde poderá dizer se quer um menu dentro do menu de contexto ou se quer apenas um link para uma aplicação.

Comece por dar o nome a esse link e vá buscar a aplicação que pretende ver associado a esse link. Eu para este exemplo vou associar ao nome pplware o Google Chrome, então coloquei o caminho para o Google Chrome. Depois cliquei no botão Generate REG file.

Ora, o que esta aplicação faz é criar dois ficheiros .reg que depois de executados pelo utilizador, escrevem no registo do Windows, abrindo as tais entradas no menu de contexto. Um dos ficheiros cria a entrada no registo, a outra remove, quando não quiser ter mais lá essa entrada.

Conforme pode ver, depois de clicar no reg que a aplicação criou e eu escolhi o lugar para a depositar e executar, o menu de contexto ganhou uma entrada nova, a tal que tem o nome pplware e abre o Chrome. Mas podemos adicionar mais aplicações.

Na opção Cascading, poderá escolher 6 opções para incluir num menu dentro do menu de contexto. O processo é o mesmo: damos o nome da entrada e escolhemos as 6 aplicações que rechearão o tal menu dentro do menu de contexto.

De novo a aplicação disparará o aviso que os dois ficheiros foram criados, dando a vez ao utilizador de concluir o processo. Vamos então ao local onde estão os ficheiros e clicamos no que permite instalar estas linhas.

As chaves e os valores contidos no reg que criamos, serão adicionados com êxito ao registo e está feita a criação de um menu rápido de acesso… ao toque do botão direito do rato.

Pode sempre alterar estas aplicações e juntar outras de seu agrado. A aplicação além de gratuita e não precisar de instalação, prepara com segurança as entradas de registo… óptimo para quem não gosta de mexer naquele ponto critico do Windows.

Licença: Freeware
Sistemas Operativos: Windows 7
Download: Your Menu 1.0 Portable [58KB]
Download: Your Menu 1.0 [356.44KB]
Homepage: Win7utilities

TweetMyPC 3.0

Publicado em 11/05/201016/09/2015 por homdigitalis

TweetMyPC 3.0 – O controlo remoto do seu PC

Criado por Pedro Simões em 7 de Maio de 2010 | 4 comentários

O TweetMyPC é uma aplicação que temos seguido atentamente pois tem características que a tornam numa ferramenta única. Este programa permite controlar o seu PC remotamente através do Twitter.

Tal como nas versões anteriores, e que vos apresentámos, esta actualização tem novidades que quase por si só representam uma nova aplicação. Está melhor, muito melhor.

Para quem não leu os artigos anteriores, a explicação sucinta do que o TweetMyPC faz é muito simples. Este software permite o envio de comandos para o Twitter e posterior interpretação por parte do vosso PC.

Na versão inicial eram apenas suportados 3 comandos muito simples e básicos: Logout (terminar sessão), Shutdown (desligar) e Restart (reiniciar).

A segunda versão trouxe para o TweetMyPC um novo conceito. A possibilidade de questionarmos o nosso PC sobre os estado em que este se encontra. Passámos a poder pedir-lhe que nos informe sobre a lista de processos a correr, qual a memória (virtual e física) que está a ser utilizada, etc. Foram ainda aumentados os comandos que passamos a poder dar ao PC.

Melhorias nesta versão

Adição de novos comandos
Resolvido o problema de tweets idênticos serem rejeitados pelo Tweeter – Basta adicionar no final do comando ###<texto> (este texto será ignorado)
Resolução de outros bugs

Comandos disponíveis (a negrito os novos)

shutdown – Este comando desliga o PC
restart – Por forma a reiniciar o PC deve executar este comando
standby – Não quer desligar o PC? Então coloque-o em standby com este comando.
hibernate -Hiberne o seu PC com um tweet.
lock – Este comando bloqueia o acesso à conta do utilizador.
logoff – Faz o logout da conta actualmente em utilização no PC
abortshutdown -Se inadvertidamente enviou um comando para desligar a máquina e quer abortar esse processo só tem de executar este comando
physical memory – Tal como o nome indica este comando devolve-nos a quantidade de memória física que está a ser utilizada.
virtual memory – Quer saber a quantidade de memória virtual do seu PC? Tweet este comando.
os – Este é, segundo o autor do software, um dos comandos com pouco valor. Invocar este comando devolve-lhe o sistema operativo do seu PC.
ip – Saiba qual o ip do seu PC de qualquer local do mundo. Especialmente útil se o seu IP é dinâmico e precisa de saber o seu IP em qualquer momento.
screenshot – Para que saiba o que se passa no seu PC é possível que seja tirada um print screen e que é enviado para o Twitpic. Óptimo para controlar o acesso ao seu PC.
getprocesslist – Este é um dos comandos mais úteis. Ao receber este comando o TweetMyPC vai gerar uma lista dos programas em execução e dos ID’s dos processos e enviar para um endereço de email pré-definido.
kill <process id> – Este pode, e deve, ser usado em conjunto com o anterior. Ao receber a lista de processos em execução pode terminar um processo usando o comando kill.
download <URL> – Quer descarregar um ficheiro mas está longe do PC? Sem problema, mande o tweet e quando voltar tem o ficheiro no PC pronto a ser usado.
getfile <filepath> – Esqueceu-se de um ficheiro importante e já não pretendia voltar para junto do PC? Simples, use este comando e esse ficheiro é enviado para o email pré-definido.
getfilelist <drive> – Queria usar o comando acima mas não se lembra da localização do ficheiro? Sem problemas, use este comando e será enviado para o email uma lista completa de ficheiro e pastas contidas na drive que indicou.
volinc – Aumenta o volume em 20%
voldec – Diminui o volume em 20%
volmute -Silencia o som do PC
volunmute – Liga de novo o som do PC
wallpaper <URL> – Defina uma imagem que achou na Internet como o desktop do seu PC
url <URL> – Abra um endereço no browser do PC
powerstate – Veja o estado da sua bateria (em carga ou quanto tempo de bateria lhe resta)
ping – Verifique o estado do TweetMyPC. Força a verificação de novos tweets
message <your message-text>– Envie uma mensagem de texto para o seu PC. Desta forma consegue interagir com quem quer que esteja em frente ao PC
stopscr – Pára o screensaver
darkscreen – Desliga o ecrã.
print <URL> – Faz download de um ficheiro e envia-o para a impressora. Apenas são suportados ficheiros do tipo .doc, .docx ou *.pdf
<Custom Command> <optional with parameters> – Este é de longe o comando mais interessante. Na verdade nem é um comando. Será apenas quando o personalizar e aplicar. Mas resumindo, defina o comando pretendido e ele é executado quando o invocar no Twitter!

Utilização

Basta descarregar o software TweetMyPC, configurar e deixá-lo na barra de tarefas para quando necessitarmos dele.

Basicamente a configuração apenas requer que coloquemos a nossa conta de Twitter e a palavra-chave de acesso à mesma. É ainda pedido que sejam indicados os dados de acesso à sua conta Gmail.

E antes de perguntarem para que razão são precisos os dados do Gmail, fica aqui a explicação muito simples: para que possam enviar e-mails através dessa conta!

Minuto a minuto, a aplicação verifica o nosso Twitter, procura por um dos comandos indicados acima e executa-os, caso existam.

É aconselhável a criação de uma conta específica do Twitter para usar com o TweetMyPC e que a mantenham privada, já que de outra forma, qualquer pessoa poderá tomar conhecimento do estado do seu PC, por exemplo, screenshots, lista de processos, e outro material sensível que coloque em causa a sua privacidade. Mantenha, por essa razão, os seus updates privados.

De qualquer modo, são apenas interpretados os updates (ou comandos) enviados por vós, e não qualquer pessoa que envie comandos para a vossa conta. Testei a partir de uma conta externa e não foi possível reiniciar o meu PC.

É importante ainda manter a sua conta Twitter dedicada a esta aplicação bem segura e com uma password bem forte, já que o acesso não autorizado à mesma poderá ter consequências menos agradáveis.

Licença: Ms-PL
Sistemas Operativos: Windows 2000/XP/Vista/7 [32 e 64 bits]
Download: TwwetMyPC v3.0 [549KB]
Homepage: TweetMyPC

Criar traduções para extensões Joomla

Publicado em 06/05/201016/09/2015 por homdigitalis

How to create translation for Joomla! extensions

This article describes how to create translation for Joomla! specific extension. As example we will build Czech language for Phoca Gallery component.

1) We will prepare folder structure for the new created translation. Create the following folders on your disc:

lang/admin
lang/site

Open text editor and paste there the following content:

1
<html><body bgcolor="#FFFFFF"></body></html>

Save it as index.html in both folders (as lang/admin/index.html and lang/site/index.html).

2) Unzip the Phoca Gallery component ZIP file somewhere on your disc. Go to:

language/en-GB/ folder (which is included in the unzipped Phoca Gallery structure)

and open both files:

en-GB.com_phocagallery.ini
en-GB.com_phocagallery.menu.ini

in text editor. Translate the strings to your langauge and save them as (in our example we use Czech prefixes):

lang/admin/cs-CZ.com_phocagallery.ini
lang/admin/cs-CZ.com_phocagallery.menu.ini
lang/site/cs-CZ.com_phocagallery.ini
lang/site/cs-CZ.com_phocagallery.menu.ini

Files should be saved as UTF-8 without BOM encoding.

3) Open text editor and paste there the following content:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<install type="language" version="1.5" client="both" method="upgrade"> <name>cs-CZ.com_phocagallery</name> <tag>cs-CZ</tag> <creationDate>01/01/2009</creationDate> <author>Jan Pavelka</author> <authorEmail>info[at]phoca[dot]cz</authorEmail> <authorUrl>http://www.phoca.cz</authorUrl> <copyright>(C) 2008 Jan Pavelka</copyright> <license>http://www.gnu.org/licenses/gpl-2.0.html GNU/GPL </license> <description>Czech language pack for Phoca Gallery</description> <administration> <files folder="admin"> <filename>cs-CZ.com_phocagallery.ini</filename> <filename>cs-CZ.com_phocagallery.menu.ini</filename> <filename>index.html</filename> </files> </administration> <site> <files folder="site"> <filename>cs-CZ.com_phocagallery.ini</filename> <filename>cs-CZ.com_phocagallery.menu.ini</filename> <filename>index.html</filename> </files> </site> </install>

Edit it and ave it as :

lang/install.xml file.

So now you should have the following folder structure in the folder lang:

install.xml
admin/index.html
admin/cs-CZ.com_phocagallery.ini
admin/cs-CZ.com_phocagallery.menu.ini
site/index.html
site/cs-CZ.com_phocagallery.ini
site/cs-CZ.com_phocagallery.menu.ini

Select all files included in lang folder and add them into ZIP file called lang-prefix-LANG-PREFIX.com_phocagallery.zip (in our example the file will have the following name: cs-CZ.com_phocagallery.zip)

Now the translation is ready and can be installed via standard Joomla! installation procedure.

Desactivar hibernação

Publicado em 26/04/201025/10/2010 por homdigitalis

Você sabia que, enquanto começa a ler este artigo, existe um grande arquivo chamado Hyberfil.sys ocupando um espaço considerável em seu HD? Isso mesmo, ele pode usar até seis gigabytes do seu disco rígido.
Esse arquivo é responsável pelo modo hibernar do seu computador. Ele ocupa todo esse espaço porque, quando o Windows entra neste modo, grava todas as informações nele e desliga os componentes da máquina. Quanto maior seu HD, mais coisas você tem e, consequentemente, maior é o tamanho do Hyberfil.sys.
Assim, quando o PC é ligado novamente, o sistema recupera tudo o que estava sendo feito através deste arquivo – e você pode continuar de onde parou.
O modo hibernar é ideal para quem usa notebooks e não tem energia de sobra. Como já amplamente discutido aqui no Portal Baixaki , é o jeito mais indicado para quem usa portáteis e precisa economizar bateria ao máximo.
Agora, se você não tem um notebook, ou simplesmente não usa o modo de hibernação, vamos mostrar aqui como desabilitá-lo e, com isso, ganhar um bom espaço no seu HD.

Desabilitando nos Windows 7 e Vista

O processo é igual para os dois sistemas operacionais. Primeiro certifique-se de estar utilizando o computador como administrador, caso contrário você não terá permissão para fazer as mudanças necessárias.
No Menu Iniciar, vá até “Executar” e digite o comando cmd.

Abre-se uma janela com o prompt do MS DOS; em seguida execute: powercfg.exe –h off

O Windows pede então que você reinicie o computador. Se ele não solicitar, faça-o manualmente. Depois de reiniciar você perceberá que o arquivo Hyberfil.sys terá sido excluído, bem como a opção de hibernar no menu de desligamento da máquina.
Para restaurar este modo, faça o mesmo caminho, executando o comando cmd. Em seguida, execute: powercfg /hibernate on.

Reinicie sua máquina e você terá novamente a opção de hibernar.

Desabilitando no Windows XP

No Windows XP o processo é diferente, porém não mais complicado. Vá até Painel de controle > Opções de energia.

Em seguida, desmarque a opção “Ativar hibernação”.

Agora, reinicie o computador e exclua o arquivo Hiberfil.sys. Espaço liberado!
Como citado anteriormente o modo hibernar é muito útil para quem usa computadores portáteis e precisa de artifícios para economizar energia. Porém em um desktops esta função já não é tão necessária, pois, se for interromper o seu uso você pode botá-lo para dormir ou até mesmo desligar a máquina.
Por isso, excluir este arquivo pode ser uma boa pedida, além é claro de render alguns gigabytes a mais. E todo mundo sabe que, quanto mais espaço houver, melhor!

Directrizes de Projecto – proteger aplicativos Web

Publicado em 26/04/201016/09/2015 por homdigitalis

Os aplicativos da Web apresentam um conjunto complexo de questões de segurança para arquitetos, designers e desenvolvedores. Os aplicativos da Web mais seguros e resistentes a ataques são aqueles que foram criados com o requisito segurança em primeiro lugar.

Você deve aplicar práticas de arquitetura e design e incorporar considerações de implantação e diretivas de segurança corporativas durante as fases iniciais do projeto. Se isso não for feito, poderá resultar em aplicativos que não podem ser implantados numa infra–estrutura existente sem comprometer a segurança.
Este módulo apresenta um conjunto de diretrizes de segurança para projeto e arquitetura. Ele foi organizado por categoria de vulnerabilidade dos aplicativos comuns. São as áreas principais de segurança dos aplicativos da Web e são as mesmas onde os erros ocorrem com mais frequência.

Objetivos

Utilize este módulo para:

• Identificar as questões principais de projeto e arquitetura de aplicativos da Web seguros.
• Considerar as principais questões de implantação no momento do projeto.
• Projetar estratégias para melhorar a validação da entrada do aplicativo da Web.
• Criar mecanismos seguros de autenticação e gerenciamento de sessões.
• Escolher um modelo de autorização apropriado.
• Implementar práticas eficientes de gerenciamento de contas e proteger as sessões dos usuários.
• Utilizar criptografia para oferecer privacidade, não–recusa, proteção contra violações e autenticação.
• Evitar a manipulação de parâmetros.
• Criar estratégias de auditoria e log.

Aplicação

Embora contidas no livro sobre segurança ASP.NET, as informações deste módulo são importantes para qualquer pessoa interessada em desenvolver aplicativos da Web seguros.

Como utilizar este módulo

O foco deste módulo está nas diretrizes e nos princípios que você deve seguir ao projetar um aplicativo.

Para aproveitar ao máximo este módulo:

• Conheça as ameaças ao seu aplicativo para que você possa garantir que isso seja solucionado pelo seu projeto.
Leia, “Ameaças e Contramedidas”, para entender as ameaças a considerar. O módulo 2 relaciona as ameaças que podem prejudicar seu aplicativo. Considere essas ameaças durante a fase de projeto.
• Use uma abordagem sistemática para as áreas principais nas quais o aplicativo poderia ficar vulnerável a ataques. Pontos nos quais se concentrar: considerações sobre a implantação; validação da entrada; autenticação e autorização; criptografia e confidencialidade dos dados; gerenciamento de configuração, sessões e exceções e auditoria e log adequados para garantir a criação de contas.

Questões de arquitetura e projeto para aplicativos da Web

Os aplicativos da Web apresentam a designers e desenvolvedores muitos desafios. Como o protocolo HTTP não mantém um registro das sessões por usuário, o registro passa a ser de responsabilidade do aplicativo. Como precursor disso, o aplicativo deve ser capaz de identificar o usuário utilizando alguma forma de autenticação. Como todas as decisões subseqüentes de autorização baseiam–se na identidade do usuário, é essencial que o processo de autenticação seja seguro e que o mecanismo de tratamento da sessão utilizado para monitorar os usuários autenticados seja igualmente bem protegido. Projetar os mecanismos de autenticação seguros e o gerenciamento de sessão é apenas parte das questões com que se deparam designers e desenvolvedores de aplicativos da Web. Outros desafios surgem porque a entrada e a saída de dados são feitos por redes públicas. Impedir a manipulação de parâmetros e a divulgação de dados confidenciais é outra questão importante.

As diretrizes de projeto apresentadas neste módulo estão organizadas por categoria de vulnerabilidade do aplicativo. A experiência mostra que um projeto deficiente nessas áreas em particular cria vulnerabilidades de segurança.

Vulnerabilidades do aplicativo da Web e possíveis problemas causados por um projeto ruim

Categoria da vulnerabilidade e possível problema causado por um projeto ruim

Validação da entrada Ataques realizados incorporando–se sequências de caracteres mal–intencionadas em sequências de caracteres de consulta, campos de formulário, cookies e cabeçalhos HTTP. Eles incluem execução de comandos, ataques XSS (cross-site scripting), inclusão de código SQL e estouro de buffer.

Autenticação Spoofing de identidade, quebra de senha, elevação de privilégios e acesso não–autorizado.

Autorização Acesso a dados confidenciais ou restritos, violação e execução de operações não–autorizadas.

Gerenciamento de configuração Acesso não–autorizado a interfaces administrativas, capacidade de atualizar dados de configuração e acesso não–autorizado a contas de usuários e perfis de contas.

Dados confidenciais Informações confidenciais divulgadas e violação de dados.

Gerenciamento de sessão Captura de identificadores de sessão, resultando em sequestro de sessão e spoofing de identidade.

Criptografia Acesso a dados confidenciais, a credenciais de contas ou a ambos.

Manipulação de parâmetros Ataques de atravessamento de caminho, execução de comando e mecanismos para ignorar o controle de acesso, entre outros, levando à divulgação de informações ,elevação de privilégios e negação de serviço.

Gerenciamento de exceções Negação de serviço e divulgação de detalhes confidenciais do sistema.

Auditoria e log Falha ao indicar sinais de invasão, incapacidade de comprovar as ações de um usuário e dificuldades no diagnóstico de problemas.

Considerações para implantação

Durante a fase de design do aplicativo, analise as diretivas e os procedimentos da empresa junto a infra–estrutura na qual seu aplicativo será implantado. Freqüentemente, o ambiente de destino é rígido e o projeto do aplicativo deve refletir as restrições. Às vezes, são necessárias mudanças no projeto, por exemplo, devido a restrições de protocolo ou porta ou topologias de implantação específicas. Identifique as restrições no início da fase de projeto para evitar surpresas mais tarde e envolver membros das equipes de rede e infra–estrutura para ajudarem nesse processo.

Políticas e procedimentos de segurança

A diretiva de segurança determina o que os aplicativos podem fazer e o que os usuários do aplicativo têm permissão para fazer. O mais importante: ela define restrições para determinar o que os aplicativos e os usuários não podem fazer. Identifique e trabalhe com a estrutura definida pela diretiva de segurança da empresa ao projetar os aplicativos para garantir que você não está violando a diretiva, o que impedirá a implantação do aplicativo.

Componentes da infra–estrutura de rede

Certifique–se de que você entendeu a estrutura de rede do ambiente de destino e os requisitos básicos de segurança da rede em termos de regras de filtragem, restrições de porta, protocolos suportados e assim por diante.
Identifique como firewalls e suas diretivas podem afetar o projeto e a implantação do aplicativo. Pode haver firewalls para separar da rede interna os aplicativos ligados diretamente à Internet. Pode haver firewalls adicionais do banco de dados. Eles podem afetar as portas de comunicação possíveis e, portanto, as opções de autenticação do servidor Web para servidores de aplicativos e de banco de dados remotos. Por exemplo, a autenticação do Windows requer portas adicionais.
Na fase de projeto, considere quais protocolos, portas e serviços podem acessar os recursos internos a partir de servidores Web localizados na rede de perímetro. Identifique também os protocolos e as portas necessários ao projeto do aplicativo e analise as ameaças que podem surgir com a abertura de novas portas ou com o uso de novos protocolos.
Comunique e registre qualquer consideração sobre a segurança na camada da rede e do aplicativo e qual componente cuidará disso. Isso evita que faltem controles de segurança quando as equipes de desenvolvimento e de rede assumirem que a outra equipe está cuidado do assunto. Preste atenção às defesas de segurança que o aplicativo espera que a rede forneça. Considere as implicações de uma alteração na configuração da rede. Quanto você perderá de segurança se implementar uma alteração específica na rede?

Topologias de implantação

A topologia de implantação do aplicativo e se existe uma camada de aplicativo remota são considerações importantes a serem incorporadas ao seu projeto. Se existir uma camada de aplicativo remota, você terá que considerar como proteger a rede entre os servidores para eliminar a ameaça de espionagem da rede e para fornecer privacidade e integridade aos dados confidenciais.

Considere também identificar o fluxo e as contas que serão utilizadas para autenticação da rede quando o aplicativo conectar–se com servidores remotos. Uma abordagem comum é utilizar pelo menos uma conta de processo privilegiada e criar uma conta duplicada (espelho) no servidor remoto com a mesma senha. Como alternativa, convém utilizar uma conta de processo de domínio, que facilita a administração, mas é mais problemática de proteger devido à dificuldade de limitar o uso da conta pela rede. Um firewall intermediário ou domínios separados sem relações de confiança geralmente fazem com que a abordagem de conta local seja a única opção viável.

Intranet, extranet e Internet

Cada um desses cenários de uso do aplicativo apresenta desafios de projeto. As questões a considerar incluem: Como você conduzirá a identidade do chamador em várias camadas de aplicativo até os recursos back–end? Onde será feita a autenticação? Você pode confiar na autenticação feita no front–end e então utilizar uma conexão confiável para acessar recursos de back–end? No caso da extranet, você também deve considerar se confia nas contas dos parceiros.
Para obter mais informações sobre questões específicas para esses e outros cenários, consulte as seções “Intranet Security”, “Extranet Security” e “Internet Security” de “Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication” em [url=”http://msdn.microsoft.com/library/en-us/dn…ecnetlpMSDN.asp”%5Dhttp://msdn.microsoft.com/library/en-us/dn…ecnetlpMSDN.asp%5B/url%5D (em inglês).

Validação da entrada

A validação da entrada é um desafio e o peso de uma solução cai sobre os ombros dos desenvolvedores do aplicativo. No entanto, a validação da entrada correta é uma das medidas de defesa mais fortes contra os ataques a aplicativos realizados atualmente. A validação da entrada correta é uma contramedida eficiente que pode ajudar a impedir ataques de scripts em sites, inclusão de código SQL e estouro do buffer, entre outros ataques de entrada.
A validação da entrada é difícil porque não há uma resposta única a o que constitui uma entrada válida entre os aplicativos e nem mesmo em cada aplicativo. Da mesma forma, não há uma única definição de entrada mal–intencionada. Além disso, o que o aplicativo faz com essa entrada influencia o risco de exploração. Por exemplo, você armazena dados para serem utilizados por outros aplicativos ou o seu aplicativo usa a entrada feita em outras fontes de dados por outros aplicativos?

As práticas a seguir melhoram a validação da entrada do aplicativo da Web:

• Considere que todas as entradas são mal–intencionadas.
• Centralize a sua abordagem.
• Não confie na validação do lado do cliente.
• Tenha cuidado com questões de canonização.
• Restrinja, rejeite e limpe a entrada.

Considere que todas as entradas são mal–intencionadas

A validação da entrada começa com a suposição fundamental de que toda entrada é mal–intencionada até que se prove o contrário. Independentemente de a entrada ter origem em um serviço, um compartilhamento de arquivo, um usuário ou de um banco de dados, valide a entrada se a fonte estiver fora do limite confiável. Por exemplo, se você chamar um Web Service externo que retornar seqüências de caracteres, como você sabe se não foram inseridos comandos mal–intencionados? Além disso, se houver vários aplicativos gravando dados em um banco de dados compartilhado, ao ler os dados, como saber se eles são seguros?

Centralize a sua abordagem

Faça da estratégia de validação da entrada um elemento básico do projeto do aplicativo. Considere uma abordagem centralizada para validação, por exemplo, utilizando um código comum de validação e filtragem em bibliotecas compartilhadas. Isso garante que as regras de validação serão aplicadas de forma consistente. Isso também reduz o trabalho de desenvolvimento e ajuda na manutenção futura.
Em muitos casos, campos individuais requerem validação específica, por exemplo, com expressões regulares desenvolvidas especialmente. No entanto, você pode freqüentemente melhorar rotinas comuns para validar campos utilizados regularmente, como endereços de email, cargos, nomes, endereços postais (incluindo CEP) e assim por diante.

Não confie na validação do lado do cliente

O código do lado do servidor deve executar sua própria validação. E se um invasor ignorar ou desativar as rotinas de script do lado do cliente, por exemplo, desativando o JavaScript? Use validação no lado do cliente para ajudar a reduzir o número de idas e vindas ao servidor, mas não confie nela para a segurança. Esse é um exemplo de defesa profunda.

Tenha cuidado com questões de canonização

Dados em forma canônica estão na sua forma padrão ou mais simples. Canonização é o processo de converter dados em sua forma canônica. Caminhos de arquivo e URLs são particularmente sujeitos a problemas de canonização e exploração bem conhecidas são o resultado direto de bugs de canonização. Por exemplo, considere a seqüência de caracteres a seguir que contém um arquivo e o caminho em sua forma canônica.

c:\temp\algumarquivo.dat

As seqüências de caracteres a seguir também poderiam representar o mesmo arquivo.
algumarquivo.dat

c:\temp\subdir\..\algumarquivo.dat
c:\ temp\ algumarquivo.dat
..\algumarquivo.dat
c%3A%5Ctemp%5Csubdir%5C%2E%2E%5Calgumarquivo.dat

No último exemplo, os caracteres foram especificados na forma hexadecimal:

• %3A representa o sinal dois–pontos.
• %5C representa uma barra invertida.
• %2E representa um ponto.

Geralmente, você deve tentar evitar projetar aplicativos que aceitam nomes de arquivo na entrada do usuário para evitar problemas de canonização. Em vez disso, considere projetos alternativos. Por exemplo, deixe o aplicativo determinar o nome do arquivo para o usuário.

Se você aceitar nomes de arquivo na entrada, certifique–se de que eles estejam estritamente formados antes de tomar decisões de segurança como autorizar ou negar acesso ao arquivo especificado.

Restrinja, rejeite e limpe a entrada

A melhor abordagem para validar a entrada é restringir desde o começo o que será permitido. É muito mais fácil validar dados de tipos, padrões e intervalos conhecidos que validá–los procurando caracteres inválidos conhecidos. Quando você projeta o aplicativo, sabe o que ele espera. O intervalo de dados válidos geralmente é um conjunto mais finito que o de entradas mal–intencionadas possíveis. No entanto, para uma defesa mais detalhada, convém rejeitar a entrada inválida conhecida e então limpá–la.

Para criar uma estratégia de validação da entrada eficiente, conheça as abordagens a seguir e suas exigências:

• Restringir a entrada.
• Validar dados por tipo, tamanho, formato e intervalo.
• Rejeitar dados inválidos.
• Limpar a entrada.

Restringir a entrada

Restringir a entrada refere–se a aceitar dados bons. Esta é a melhor abordagem. A idéia é definir um filtro de entradas aceitáveis utilizando tipo, tamanho, formato e intervalo. Defina o que é uma entrada aceitável para os campos do aplicativo e a aplique. Rejeite o restante como dados inválidos.
A restrição da entrada deve envolver a definição de conjuntos de caracteres no servidor para que você possa estabelecer a forma canônica da entrada de maneira localizada.

Validar os dados por tipo, tamanho, formato e intervalo

Use uma verificação de tipo rígida da entrada de dados sempre que possível, por exemplo, em classes utilizadas para manipular e processar os dados da entrada e em rotinas de acesso a dados. A exemplo disto, utilize procedimentos armazenados com parâmetros para acessar dados a fim de aproveitar a verificação de tipo dos campos de entrada.
Verifique também os campos de seqüências de caracteres e, muitas vezes, se seu formato é apropriado. Por exemplo, CEPs, números de RG, etc. têm formatos definidos que podem ser validados utilizando–se expressões regulares. A verificação completa não é a única boa prática de programação; ela dificulta que um invasor explore o código. O invasor pode passar pela verificação de tipo, mas a verificação de tamanho pode dificultar a execução de seu ataque favorito.

Rejeitar dados inválidos

Rejeite dados “inválidos”, mas não dependa totalmente dessa abordagem. Geralmente, ela é menos eficiente que utilizar a abordagem de “permissão” descrita anteriormente e é melhor usá–la de forma combinada. Para negar dados inválidos, assume–se que o aplicativo conhece todas as variações de uma entrada mal–intencionada. Lembre–se de que existem várias formas de representar caracteres. Esse é um outro motivo pelo qual a “permissão” é a abordagem preferida.
Embora seja útil para aplicativos que já estão em uso e quando você não pode arcar com alterações significativas, a abordagem de “negação” não é tão robusta como a de “permissão” pode os dados inválidos, como padrões que podem ser utilizados para identificar ataques comuns, não são constantes. Os dados válidos são constantes enquanto os dados inválidos podem variar periodicamente.

Limpar a entrada

Quando falamos em limpeza, significa transformar dados possivelmente mal–intencionados em dados seguros. Isso pode ser útil quando o intervalo de entrada permitido não pode garantir que a entrada é segura. Isso inclui qualquer coisa desde separar um valor nulo do final de uma seqüência de caracteres fornecida pelo usuário até remover valores para que sejam tratados como literais.
Outro exemplo comum de limpeza da entrada de aplicativos da Web é utilizar codificação de URL ou HTML para combinar dados e tratá–los como texto literal em vez de como script executável. Os métodos de HtmlEncode removem caracteres HTML e UrlEncode codificam um URL para que ele seja uma solicitação URI válida.

Na prática

Seguem exemplos aplicados a campos de entrada comuns utilizando as abordagens citadas:

• Campo Sobrenome. Este é um bom exemplo de onde a restrição da entrada é apropriada. Nesse caso, convém restringir os dados da seqüência de caracteres no intervalo ASCII A–Z e a–z e também em hífens e apóstrofes (apóstrofes não significam nada para o SQL) para tratar nomes como O’Dell. Também é ideal limitar a extensão ao maior valor esperado.
• Campo Quantidade. Este é outro caso em que a restrição da entrada funciona bem. Neste exemplo, convém utilizar uma restrição simples de tipo e intervalo. Por exemplo, os dados da entrada podem precisar ser um número inteiro positivo entre 0 e 1000.
• Campo Texto livre. Os exemplos incluem campos de comentário em quadros de discussão. Nesse caso, convém permitir o uso de letras e espaços além de caracteres comuns, como apóstrofes, vírgulas e hífens. O conjunto do que é permitido não inclui sinais de maior que e menor que, chaves e colchetes.
Alguns aplicativos podem permitir que os usuários marquem o texto utilizando um conjunto finito de caracteres de script, como negrito “” e itálico ““, ou até mesmo incluam um link para o URL favorito. No caso de um URL, a validação deve codificar o valor para que ele seja tratado como URL.

Um aplicativo da Web existente que não valida a entrada do usuário. Em um cenário ideal, o aplicativo verifica se a entrada de cada campo ou ponto de entrada é aceitável. No entanto, se você já possui um aplicativo da Web que não valida a entrada do usuário, você precisa de uma abordagem “quebra galho” para reduzir o risco até que seja possível aprimorar a estratégia de validação da entrada do aplicativo. Embora nenhuma das abordagens a seguir garantam um tratamento seguro da entrada, pois dependem de fatores como de onde vem a entrada e como ela será utilizada no aplicativo, elas são empregadas atualmente como correções rápidas para melhorar a segurança em curto prazo:

• Codificar como HTML e URL a entrada do usuário ao gravar de volta no cliente. Nesse caso, considera–se que nenhuma entrada é tratada como HTML e todas as saída são gravadas de volta de forma protegida. Essa é uma ação de limpeza.
• Rejeitar caracteres de script mal-intencionados. Esse é um caso de rejeição de entrada inválida conhecida. Nesse caso, um conjunto configurável de caracteres mal–intencionados é utilizado para rejeitar a entrada. Como descrito anteriormente, o problema dessa abordagem é um dado considerado inválido de acordo com o contexto.

Autenticação

Autenticação é o processo pelo qual se determina a identidade do chamador. Existem três aspectos a considerar:

• Identificar onde a autenticação é necessária no aplicativo. Geralmente, ela é requerida sempre que um limite confiável é ultrapassado. Os limites confiáveis normalmente incluem conjuntos, processos e hosts.
• Validar quem é o chamador. Os usuários geralmente se autenticam com nomes de usuário e senhas.
• Identificar o usuário nas solicitações subseqüentes. Isso requer alguma forma de identificador de autenticação.
Muitos aplicativos da Web usam um mecanismo de senha para autenticar usuários, sendo que o usuário fornece um nome de usuário e uma senha em formato HTML. As questões a considerar nesse caso incluem:
• Os nomes de usuário e senhas são enviados em texto sem formatação por um canal inseguro? Se sim, um invasor pode utilizar um software de monitoramento de rede para espionar e capturar as credenciais. A contramedida aqui é proteger o canal de comunicação utilizando SSL (Secure Socket Layer).
• Como as credenciais são armazenadas? Se você estiver armazenando nomes de usuário e senhas em texto sem formatação, em arquivos ou em um banco de dados, está procurando problemas. E se o diretório do aplicativo não estiver configurado corretamente e um invasor procurar um arquivo e baixar seu conteúdo ou incluir uma conta de logon com privilégios? E se um administrador descontente levar seu banco de dados de nomes de usuário e senhas?
• Como as credenciais são verificadas? Não é necessário armazenar senhas de usuário se a única finalidade for verificar se o usuário conhece a senha. Em vez disso, você pode armazenar um verificador na forma de um valor de hash e recalcular o hash utilizando o valor fornecido pelo usuário durante o processo de logon. Para eliminar a ameaça de um ataque de dicionário contra o armazenamento de credenciais, utilize senhas de alta segurança e combine um valor falso gerado aleatoriamente com o hash da senha.
• Como o usuário autenticado é identificado após o logon inicial? É necessária alguma forma de permissão de autenticação como, por exemplo, um cookie de autenticação. Como o cookie é protegido? Se ele for enviado por um canal desprotegido, um invasor pode capturá–lo e usá–lo para acessar o aplicativo. Um cookie de autenticação roubado é um logon roubado.

As práticas a seguir melhoram a autenticação do aplicativo da Web:

• Separar áreas públicas e restritas.
• Utilizar diretivas de bloqueio de conta para as contas de usuário final.
• Utilizar senhas com data de validade.
• Poder desativar contas.
• Não armazenar senhas nos armazenamentos de usuários.
• Exigir senhas de alta segurança.
• Não transmitir senhas em texto sem formatação.
• Proteger os cookies de autenticação.

Separar áreas públicas e restritas

A área pública do seu site pode ser acessada por qualquer usuário de forma anônima. As áreas restritas só podem ser acessadas por pessoas específicas e os usuários devem ser autenticados no site. Considere um site comum de uma loja. Você pode navegar pelo catálogo de produtos de forma anônima. Quando você inclui itens no carrinho de compra, o aplicativo identifica você utilizando um identificador de sessão. Finalmente, quando você faz o pedido, realiza uma transação segura. Nesse ponto, você precisa fazer logon para autenticar sua transação pela SSL.
Dividindo o site em áreas de acesso pública e restrita, você pode aplicar regras de autenticação e autorização a todo o site e limitar o uso da SSL. Para evitar a sobrecarga desnecessária sobre o desempenho provocado pela SSL, projete o site de modo a limitar o uso da SSL nas áreas que requerem acesso autenticado.
Utilizar diretivas de bloqueio de conta para as contas de usuário final

Desative contas de usuário final ou a gravação de eventos em log depois de um número determinado de tentativas de logon sem sucesso. Se você estiver utilizando a autenticação do Windows, como NTLM ou o protocolo Kerberos, essas diretivas podem ser configuradas e aplicadas automaticamente pelo sistema operacional. Com autenticação de formulários, essas diretivas são responsabilidade do aplicativo e devem ser incorporadas ao projeto do mesmo.
Tenha cuidado para que as diretivas de bloqueio de contas não sejam utilizadas em ataques de negação de serviço. Por exemplo, contas de serviço padrão conhecidas, como IUSR_MACHINENAME, devem ser substituída por nomes de contas personalizados para evitar que um invasor que consiga obter o nome do servidor Web do IIS (Internet Information Services) bloqueie essa conta vital.

Utilizar senhas com data de validade

As senhas não devem ser estáticas e sim alteradas como parte da rotina de manutenção de senha por meio de períodos de validade da senha. Considere fornecer esse tipo de recurso ao projetar o aplicativo.

Poder desativar contas

Se o sistema estiver comprometido, poder invalidar deliberadamente credenciais ou desativar contas pode evitar outros ataques.

Não registrar senhas nos armazenamentos de usuários

Se você deve verificar as senhas, não é necessário realmente armazená–las. Em vez disso, armazene um valor de hash unidirecional e então recalcule o hash utilizando as senhas fornecidas pelos usuários. Para eliminar a ameaça de um ataque de dicionário contra o armazenamento do usuário, utilize senhas de alta segurança e incorpore um valor falso gerado com a senha.

Exigir senhas de alta segurança

Não facilite a quebra de senhas para os invasores. Existem muitas instruções, mas uma prática geral é exigir no mínimo oito caracteres e uma mistura de letras maiúsculas e minúsculas, números e caracteres especiais. Tanto se você estiver utilizando uma plataforma para aplicar essas regras ou quanto se estiver desenvolvendo sua própria validação, essa etapa é necessária para combater ataques de força bruta, nos quais o invasor tenta quebrar uma senha sistematicamente por tentativa e erro. Utilize expressões regulares para ajudar na validação de senhas de alta segurança.

Não transmitir senhas em texto sem formatação

Senhas em texto sem formatação enviadas por uma rede ficam vulneráveis à espionagem. Para acabar com essa ameaça, você precisa proteger o canal de comunicação como, por exemplo, utilizar SSL para criptografar o tráfego.

Proteger os cookies de autenticação

Um cookie de autenticação roubado é um logon roubado. Proteja as permissões de autenticação utilizando criptografia e canais de comunicação seguros. Além disso, limite o tempo de validade de uma permissão de autenticação para combater a ameaça de spoofing que pode resultar de ataques de repetição, nos quais o invasor captura o cookie e o usa para obter acesso ilegal ao site. Reduzir o tempo limite do cookie não evita ataques de repetição, mas limita o tempo pelo qual o invasor terá acesso ao site utilizando o cookie roubado.

Autorização

A autorização determina o que a identidade autenticada pode realizar e quais recursos ela acessa. Uma autorização incorreta ou ineficaz leva à divulgação de informações e à violação dos dados. Defesa profunda é o princípio básico de segurança utilizado na estratégia de autorização do aplicativo.

As práticas a seguir melhoram a autorização do aplicativo da Web:

• Utilizar vários gatekeepers.
• Restringir o acesso do usuário a recursos no nível do sistema.
• Considerar a granulação da autorização.

Utilizar vários gatekeepers

No lado do servidor, você pode utilizar as diretivas do IPSec (IP Security Protocol) para definir restrições do host a fim de restringir a comunicação entre servidores. Por exemplo: uma diretiva IPSec poderia restringir a conexão de qualquer host separado de um servidor Web com um servidor de banco de dados. O IIS fornece permissões da Web e restrições IP/DNS (Internet Protocol/Domain Name System). As permissões da Web do IIS são válidas para todos os recursos solicitados pelo HTTP independentemente do usuário. Elas não oferecem proteção se um invasor tiver como realizar logon no servidor. Por isso, as permissões de NTFS consentem que você especifique listas de controle de acesso por usuário. Finalmente, o ASP.NET fornece autorização de URL e de arquivo junto a demanda de permissão principal. Combinando esses gatekeepers, você pode desenvolver uma estratégia de autorização eficiente.

Restringir o acesso do usuário a recursos no nível do sistema

Os recursos no nível do sistema incluem arquivos, pastas, chaves do registro, objetos do Active Directory, objetos do banco de dados, logs de evento, etc. Utilize as listas de controle de acesso do Windows para restringir quais usuários podem acessar quais recursos e os tipos de operação que eles podem executar. Preste atenção especialmente nas contas de usuário anônimas da Internet; utilize as listas de controle de acesso para restringi–las a recursos que negam acesso explicitamente a usuários anônimos.

Considerar a granulação da autorização

Existem três modelos comuns de autorização, cada um com graus diferentes de granulação e escalabilidade.
A abordagem mais granular depende de representação. O acesso aos recursos ocorre utilizando o contexto de segurança do chamador. As listas de controle de acesso do Windows dos recursos protegidos (geralmente arquivos ou tabelas, ou ambos) determinam se o chamador pode acessar o recurso. Se o aplicativo fornecer acesso basicamente a recursos específicos do usuário, essa abordagem pode ser válida. Sua vantagem é que a auditoria no nível do sistema operacional pode ser feita entre as camadas do aplicativo, pois o contexto de segurança do chamador original flui no nível do sistema operacional e é utilizado para acessar recursos. No entanto, seu problema é a escalabilidade do aplicativo, pois não é possível estabelecer um pool de conexão eficiente para acessar o banco de dados. Como resultado, essa abordagem é encontrada com mais freqüência em aplicativos para intranet de escala limitada.

A abordagem menos granular, porém mais escalonável, utiliza a identificação de processo do aplicativo para acessar recursos. Ela oferece suporte ao pool de conexão ao banco de dados, mas isso significa que as permissões concedidas à identificação do aplicativo no banco de dados são comuns, independentemente da identificação do chamador original. A autorização principal é feita na camada intermediária lógica do aplicativo utilizando funções, agrupando usuários que compartilham os mesmos privilégios com relação ao aplicativo. O acesso a classes e métodos é restringido de acordo com a participação do chamador na função. Para oferecer suporte à recuperação de dados por usuário, uma abordagem comum é inclui uma coluna de identificação nas tabelas do banco de dados e utilizar parâmetros de consulta para restringir os dados recuperados. Por exemplo: você pode passar a identificação do chamador original para o banco de dados no nível do aplicativo (não do sistema operacional) por meio de parâmetros de procedimentos armazenados e gravar consultas semelhantes a estas:

SELECT field1, field2, field3 FROM Table1 WHERE {some search criteria} AND

UserName = @originalCallerUserName

Esse modelo é conhecido como subsistema confiável ou, às vezes, como modelo de servidor confiável.
A terceira opção é utilizar um conjunto limitado de identidades para acessar recursos com base na participação do chamador na função. Na verdade, trata–se de um híbrido dos dois modelos descritos anteriormente. Os chamadores são mapeados para funções na camada intermediária lógica do aplicativo e o acesso a classes e métodos é restrito de acordo com a participação na função. O acesso a recursos de downstream é feito utilizando um conjunto restrito de identidade determinado pela participação na função do chamador atual. A vantagem dessa abordagem é que as permissões podem ser atribuídas a logons separados no banco de dados e a regulagem da conexão ainda ser efetiva com diversos pools de conexões. A desvantagem é que a criação dos símbolos de acesso com vários segmentos utilizados para estabelecer contextos diferentes de segurança para acessar recursos de downstream utilizando a autenticação do Windows é uma operação com privilégios que requer contas de processo com privilégios. Isso vai contra o princípio de menos privilégios.

Gerenciamento de configuração

Considere atentamente a funcionalidade de gerenciamento de configuração do aplicativo da Web. A maioria dos aplicativos requer interfaces que permitem que desenvolvedores de conteúdo, operadores e administradores configurem o aplicativo e gerenciem itens como conteúdo de páginas da Web, contas de usuário, informações do perfil do usuário e seqüências de caracteres para conexão do banco de dados. Se houver suporte para administração remota, como as interfaces de administração são protegidas? As conseqüências de uma falha de segurança em uma interface administrativa podem ser graves, pois o invasor freqüentemente acaba utilizando privilégios de administrador e tem acesso direto a todo o site.

As práticas a seguir aumentam a segurança do gerenciamento da configuração do aplicativo da Web:

• Proteger as interfaces administrativas.
• Proteger o armazenamento da configuração.
• Manter privilégios administrativos distintos.
• Utilizar contas com processos e serviços com a menor quantidade de privilégios.

Proteger as interfaces administrativas

É importante que a funcionalidade de gerenciamento da configuração seja acessível somente por operadores e administradores autorizados. O principal é aplicar uma autenticação rígida nas interfaces administrativas, por exemplo, utilizando certificados.

Se possível, limite ou evite o uso da administração remota e exija que os administradores façam logon localmente. Se você precisar oferecer suporte a administração remota, use canais criptografados, por exemplo, com tecnologia de SSL VPN, devido à natureza confidencial dos dados transmitidos pelas interfaces administrativas. Considere também limitar a administração remota a computadores da rede interna utilizando diretivas IPSec para diminuir ainda mais o risco.

Proteger o armazenamento da configuração

Arquivos de configuração em texto, o registro e os bancos de dados são as opções comuns para armazenamento dos dados de configuração do aplicativo. Se possível, evitar utilizar arquivos de configuração no espaço da Web do aplicativo para evitar possíveis vulnerabilidades no servidor de configuração, resultando no download dos arquivos de configuração. Independentemente da abordagem utilizada, proteja o acesso ao armazenamento da configuração, por exemplo, utilizando as listas de controle de acesso do Windows ou permissões do banco de dados. Além disso, evite armazenar informações confidenciais, como seqüências de caracteres de conexão do banco de dados ou credenciais de contas, em texto sem formatação. Proteja esses itens utilizando criptografia e restrinja o acesso à chave do registro, ao arquivo ou à tabela que contém os dados criptografados.

Manter privilégios administrativos distintos

Se a funcionalidade suportada pelos recursos do gerenciamento da configuração do aplicativo varia de acordo com a função do administrador, considere autorizar cada função separadamente utilizando a autorização com base na função. Por exemplo: a pessoa responsável por atualizar o conteúdo estático do site não precisa ter permissão para alterar o limite de crédito de um cliente.
Utilizar contas com processos e serviços com a menor quantidade de privilégios
Um aspecto importante da configuração do aplicativo são as contas de processo utilizadas para executar processos no servidor Web e as contas de serviço utilizadas para acessar recursos de downstream e sistemas. Certifique–se de que essas contas estejam configuradas com a menor quantidade de privilégios. Se um invasor conseguir assumir o controle de um processo, a identificação do processo deve ter acesso extremamente restrito ao sistema de arquivos e a outros recursos do sistema para limitar os danos que podem ser causados

Dados confidenciais

Os aplicativos que lidam com informações particulares dos usuários, como números de cartão de crédito, endereços, registros médicos e outros, devem seguir etapas especiais para garantir que os dados permanecerão particulares e inalterados. Além disso, os segredos utilizados na implementação do aplicativo, como senhas e seqüências de conexão ao banco de dados, devem ser protegidos. A segurança de dados confidenciais é um problema enquanto os dados são armazenados em um local de armazenamento persistente e enquanto são transmitidos pela rede.

Segredos

Os segredos incluem senhas, seqüências de caracteres de conexão ao banco de dados e números de cartão de crédito. As práticas a seguir aumentam a segurança do tratamento dos segredos feito pelo aplicativo da Web:

• Não armazenar segredos se for possível evitar.
• Não armazenar segredos no código.
• Não armazenar conexões ao banco de dados, senhas ou chaves em texto sem formatação.
• Evitar armazenar segredos na LSA (autoridade de segurança local).
• Utilizar a DAPI (API de Proteção a Dados) para criptografar os segredos.

Não armazenar segredos se for possível evitar

Armazenar segredos em software de maneira totalmente segura é impossível. Um administrador, com acesso físico ao servidor, pode acessar os dados. Não é necessário armazenar um segredo quando tudo o que você precisa fazer é verificar se o usuário o conhece. Nesse caso, você pode armazenar um valor de hash que representa o segredo e calcula o hash utilizando o valor fornecido pelo usuário para verificar se o usuário conhece o segredo.

Não armazenar segredos no código

Não inclua os segredos no código. Mesmo que o código–fonte não seja exposto no servidor Web, é possível extrair constantes de seqüências de caracteres de arquivos executáveis compilados. Uma vulnerabilidade na configuração pode permitir que um invasor recupere o executável.
Não armazenar conexões ao banco de dados, senhas ou chaves em texto sem formatação
Evite armazenar segredos como seqüências de caracteres de conexões ao banco de dados, senhas ou chaves em texto sem formatação. Utilize criptografia e armazene seqüências de caracteres criptografadas.

Evitar armazenar segredos na LSA

Evitar a LSA porque o aplicativo requer privilégios administrativos para acessá–la. Isso viola o princípio de segurança básico de utilizar a menor quantidade de privilégios. Além disso, a LSA pode armazenar segredos somente em um número restrito de slots. O melhor é utilizar a DPAPI, disponível no Microsoft Windows® 2000 e nos sistemas operacionais posteriores.

Utilizar DPAPI para criptografar os segredos

Para armazenar segredos como seqüências de caracteres de conexão a banco de dados ou credenciais de serviço das contas, use DPAPI. A principal vantagem de utilizar a DPAPI é que o sistema da plataforma gerencia a chave de criptografia/descriptografia e isso não é problema para o aplicativo. A chave é vinculada a uma conta de usuário do Windows ou a um computador específico, dependendo dos sinalizadores passados para as funções da DPAPI.
A DPAPI é mais adequada para criptografar informações, pois pode ser recriada manualmente em caso de perda das chaves mestre, por exemplo, devido a um dano no servidor que exija a reinstalação do sistema operacional. Dados que não podem ser recuperados porque você conhece o valor sem formatação, por exemplo, detalhes do cartão de crédito do cliente, requerem uma abordagem alternativa que usa a criptografia com base em chave simétrica tradicional, como a utilizada no triplo DES.

Dados confidenciais por usuário

Dados confidenciais, como credenciais de logon, e dados no nível do aplicativo, como números de cartão de crédito, números de contas bancárias, etc., precisam ser protegidos. A privacidade por meio da criptografia e a integridade através de códigos de autenticação de mensagens (MAC) são os elementos principais.

As práticas a seguir aumentam a segurança de dados confidenciais por usuário em aplicativos da Web:

• Recuperar dados confidenciais sob demanda.
• Criptografar os dados ou proteger o canal de comunicação.
• Não armazenar dados confidenciais em cookies persistentes.
• Não transmitir dados confidenciais utilizando o protocolo HTTP–GET.

Recuperar dados confidenciais sob demanda

A melhor abordagem é recuperar dados confidenciais sob demanda quando eles forem necessários em vez de mantê–los ou armazená–los em cache na memória. Por exemplo: recupere o segredo criptografado quando ele for necessário, descriptografe–o e limpe a memória (variável) uutilize para manter o segredo em texto sem formatação. Se a questão for o desempenho, considere estas opções:

• Armazenar em cache o segredo criptografado.
• Armazenar em cache o segredo em texto sem formatação.

Armazenar em cache o segredo criptografado

Recupere o segredo quando o aplicativo for carregado e o armazene em cache na memória, descriptografando–o quando o aplicativo usá–lo. Apague a cópia em texto sem formatação quando ela não for mais necessária. Essa abordagem evita o acesso ao armazenamento de dados a cada solicitação.

Armazenar em cache o segredo em texto sem formatação

Evite a sobrecarga de descriptografar o segredo várias vezes e armazenar a cópia em texto sem formatação do segredo na memória. Essa é a abordagem menos segura, mas oferece o melhor desempenho. Teste as outras abordagens antes de achar que o ganho em desempenho compensa o risco de segurança maior.
Criptografar os dados ou proteger o canal de comunicação

Se você estiver enviando ao cliente dados confidenciais pela rede, criptografe–os ou proteja o canal. Uma prática comum é utilizar SSL entre o cliente e o servidor Web. Entre servidores, a abordagem cada vez mais comum é utilizar IPSec. Para proteger dados confidenciais que trafegam entre vários intermediários, por exemplo, mensagens SOAP (Simple Object Access Protocol) do Web Service, usam criptografia no nível da mensagem.

Não armazenar dados confidenciais em cookies persistentes

Evite armazenar dados confidenciais em cookies persistentes. Se você armazenar dados em texto sem formatação, o usuário final poderá ver e modificar os dados. Se você criptografar os dados, o gerenciamento de chaves pode ser um problema. Por exemplo, a chave utilizada para criptografar os dados no cookie expirou e foi reciclada, a nova chave não consegue descriptografar o cookie persistente transmitido pelo navegador a partir do cliente.
Não transmitir dados confidenciais utilizando o protocolo HTTP–GET
Você pode evitar armazenar dados confidenciais utilizando o protocolo HTTP–GET porque ele usa seqüências de caracteres de consulta para transmitir dados. Não é possível proteger dados confidenciais utilizando seqüências de caracteres de consulta e estas são freqüentemente registradas pelo servidor

Gerenciamento de sessão

Os aplicativos da Web baseiam–se no protocolo HTTP independente, portanto, o gerenciamento da sessão é responsabilidade do aplicativo. A segurança da sessão é fundamental para a segurança geral do aplicativo.
As práticas a seguir aumentam a segurança do gerenciamento da sessão do aplicativo da Web:

• Utilizar SSL para proteger os cookies de autenticação da sessão.
• Criptografar o conteúdo dos cookies de autenticação.
• Limitar a duração da sessão.
• Proteger o estado da sessão contra acesso não autorizado.

Utilizar SSL para proteger os cookies de autenticação da sessão

Não transmita cookies de autenticação por conexões HTTP. Defina o cookie seguro corretamente nos cookies de autenticação, que instruem os navegadores a retornar os cookies ao servidor somente por conexões HTTPS.
Criptografar o conteúdo dos cookies de autenticação
Criptografe o conteúdo do cookie mesmo que você esteja utilizando SSL. Isso evita que um invasor visualize ou modifique o cookie se ele conseguir roubá–lo por meio de um ataque de scripts através de sites. Nesse caso, o invasor ainda poderia utilizar o cookie para acessar o aplicativo, mas somente enquanto ele fosse válido.

Limitar a duração da sessão

Reduza o tempo de duração das sessões para reduzir o risco de seqüestro de sessão e ataques de repetição. Quanto menor a sessão, menos tempo o invasor terá para capturar um cookie da sessão usá–lo para acessar o aplicativo.
Proteger o estado da sessão contra acesso não autorizado

Considere como o estado da sessão será armazenado. Para um melhor desempenho, você pode armazená–lo no espaço de endereço do processo do aplicativo da Web. No entanto, essa abordagem tem escalabilidade limitada e implicações em cenários de Web farm, nos quais não há garantia de que as solicitações do mesmo usuário serão tratadas pelo mesmo servidor. Nesse caso, é necessário um estado fora do processo em um servidor de estado dedicado ou um armazenamento de estado persistente em um banco de dados compartilhado. O ASP.NET suporte as três opções.
Você deve proteger o link de rede entre o aplicativo da Web e o armazenamento de estado utilizando IPSec ou SSL para reduzir o risco de espionagem. Considere também como o aplicativo da Web será autenticado pelo armazenamento de estado. Utilize a autenticação do Windows sempre que possível para evitar transmitir credenciais de autenticação em texto sem formatação pela rede e para aproveitar as diretivas de contas seguras do Windows.

Criptografia

A criptografia em sua forma básica oferece o seguinte:

• Privacidade (Confidencialidade). Esse serviço mantém um segredo como confidencial.
• Não-repúdio (Autenticidade). Esse serviço garante que um usuário não pode negar o envio de uma mensagem em particular.
• À prova de violação (Integridade). Esse serviço evita que os dados sejam alterados.
• Autenticação. Esse serviço confirma a identidade do remetente de uma mensagem.

Os aplicativos da Web freqüentemente usam criptografia para protege dados em armazenamentos persistentes ou enquanto são transmitidos pelas redes. As práticas a seguir aumentam a segurança do aplicativo da Web quando você utilizar criptografia:

• Não desenvolver sua própria criptografia.
• Manter dados descriptografados próximos do algoritmo.
• Utilizar o algoritmo e o tamanho de chave corretos.
• Proteger as chaves de criptografia.

Não desenvolver sua própria criptografia

Algoritmos e rotinas de criptografia são notoriamente difíceis de desenvolver com sucesso. Como resultado, você deve utilizar os serviços de criptografia testados fornecidos pela plataforma. Isso inclui o .NET Framework e o sistema operacional subjacente. Não desenvolva implementações personalizadas porque, geralmente, resultam em uma proteção fraca.

Manter dados descriptografados próximos do algoritmo

Ao transmitir texto sem formatação a um algoritmo, não obtenha os dados até que você esteja pronto para usá–los e armazená–los no menor número de variáveis possível.

Utilizar o algoritmo e o tamanho de chave corretos

É importante garantir que você escolheu o algoritmo certo para o trabalho certo e que você está utilizando um tamanho de chave que fornece um grau suficiente de segurança. Chaves maiores geralmente aumentar a segurança. A lista a seguir resume os principais algoritmos com o tamanho de chave que cada um usa:

• Chave DES (Data Encryption Standard) de 64 bits (8 bytes)
• Chave triplo DES de 128 bits ou chave de 192 bits (16 ou 24 bytes)
• Chaves Rijndael de 128 – 256 bits (16 – 32 bytes)
• Chaves RSA de 384 – 16.384 bits (48 – 2.048 bytes)

Para criptografar dados maiores, utilize o algoritmo de criptografia simétrica Triplo DES. Para criptografia mais lenta e mais rígida de grandes quantidades de dados, use Rijndael. Para criptografar os dados que serão armazenados por curtos períodos, você pode considerar o uso de um algoritmo mais rápido, mas mais fraco, como o DES. Para assinaturas digitais, utilize RSA (Rivest, Shamir e Adleman) ou DAS (Digital Signature Algorithm). Para hash, utilize o SHA (Secure Hash Algorithm)1.0. Para hashes com chaves, utilize o HMAC (Hash–based Message Authentication Code) SHA1.0.

Proteger as chaves de criptografia

A chave de criptografia é um número secreto utilizado como entrada para processos de criptografia e descriptografia. Para que os dados criptografados continuem seguros, a chave deve ser protegida. Se um invasor comprometer a chave de descriptografia, os dados criptografados não estarão mais seguros.
As práticas a seguir ajudam a proteger as chaves de criptografia:

• Utilizar a DPAPI para evitar o gerenciamento de chaves.
• Mudar as chaves periodicamente.

Utilizar a DPAPI para evitar o gerenciamento de chaves

Como já foi citado, uma das maiores vantagens do uso da DPAPI é que a questão do gerenciamento de chaves fica a cargo do sistema operacional. A chave utilizada pela DPAPI é derivada da senha associada à conta de processo que aciona as funções da DPAPI. Use a DPAPI para deixar o trabalho de gerenciamento de chaves para o sistema operacional.

Mudar as chaves periodicamente

Geralmente, a probabilidade de um segredo estático ser descoberto com o tempo é maior. As questões que você não pode esquecer incluem: Você o anotou em algum lugar? Bob, o administrador que detém os segredos, mudou de cargo ou saiu da empresa? Não use demais as chaves.

Manipulação de parâmetros

Com ataques de manipulação de parâmetros, o invasor modifica os dados transmitidos entre o cliente e o aplicativo da Web. Podem ser dados enviados por meio de seqüências de caracteres de consulta, campos de formulário, cookies ou em cabeçalhos HTTP. As práticas a seguir ajudam a proteger a manipulação de parâmetros do aplicativo da Web:

• Criptografar o estado de cookies confidenciais.
• Certificar–se de que os usuários não ignoram as verificações.
• Validar todos os valores enviados a partir do cliente.
• Não confiar nas informações do cabeçalho HTTP.

Criptografar o estado de cookies confidenciais

Os cookies podem conter dados confidenciais, como identificadores de sessão, ou dados utilizados no processo de autorização do lado do servidor. Para proteger esse tipo de dados contra manipulação não–autorizada, criptografe o conteúdo do cookie.

Certificar–se de que os usuários não ignoram as verificações

Certifique–se de que os usuários não ignoram as verificações manipulando parâmetros. Os parâmetros de URL podem ser manipulados pelos usuários finais através da caixa de texto de endereço do navegador. Por exemplo: o URL [url=”http://www.//IDsessão=10″%5Dhttp://www.//IDsessão=10%5B/url%5D possui um valor de 10 que pode ser alterado para algum número aleatório para receber uma saída diferente. Certifique–se de verificar isso no código do lado do servidor, não no JavaScript no lado do cliente, que pode ser desativado no navegador.

Validar todos os valores enviados a partir do cliente

Restrinja os campos que o usuário pode inserir e modificar e valide todos os valores provenientes do cliente. Se você predefiniu valores em campos de formulário, os usuários podem alterá–los e retorná–los para receber resultados diferentes. Permita somente valores bem conhecidos sempre que possível. Por exemplo, se o campo de entrada for um estado, somente entradas que correspondam ao código postal do estado devem ser permitidas.

Não confiar nas informações do cabeçalho HTTP

Os cabeçalhos HTTP são enviados no início das solicitações e das respostas HTTP. O aplicativo da Web deve certificar–se de que ele não baseia nenhuma decisão de segurança nas informações contidas nos cabeçalhos HTTP porque é fácil para um invasor manipular o cabeçalho. Por exemplo, o campo referencial do cabeçalho contém o URL da página da Web de onde ele provém. Não tome decisões de segurança com base no valor do campo referencial, por exemplo, verificar se a solicitação teve origem em uma página gerada pelo aplicativo da Web, pois o campo pode ser facilmente falsificado.

Gerenciamento de exceções

O tratamento seguro de exceções pode ajudar a evitar certos ataques de negação de serviço no nível do aplicativo e também pode ser utilizado para impedir que informações importantes no nível do sistema úteis aos invasores sejam retornadas ao cliente. Por exemplo, sem o tratamento correto de exceções, informações como detalhes do esquema do banco de dados, versões do sistema operacional, rastreamentos de pilha, nomes e caminho de arquivos, seqüências de caracteres de consulta do SQL e outras informações de valor para o invasor podem ser retornadas ao cliente.
Uma boa abordagem é projetar um gerenciamento de exceções centralizado e uma solução de registro em log e considerar a inclusão de ganchos no sistema de gerenciamento de exceções para oferecer suporte à instrumentação e ao monitoramento centralizado para ajudar os administradores de sistema.

As práticas a seguir ajudam a proteger o gerenciamento de exceções do aplicativo da Web:

• Não deixar vazar informações para o cliente.
• Registrar em log mensagens de erro com detalhes.
• Identificar as exceções.

Não deixar vazar informações para o cliente

No caso de falha, não exponha informações que poderiam resultar na divulgação de informações. Por exemplo, não exponha detalhes do rastreamento de pilha que incluam nomes de função e números de linha no caso de compilações para depuração (que não devem ser utilizadas em servidores de produção). Em vez disso, retorne mensagens de erro genéricas ao cliente.

Registrar em log mensagens de erro com detalhes
Envie mensagens de erro detalhadas ao log de erros. Envie o mínimo de informações ao usuário do serviço ou do aplicativo, como uma mensagem de erro genérica e uma identificação personalizada do log de erro que possa ser então mapeada até a mensagem detalhada nos logs de eventos. Certifique–se de não registrar no log senhas nem outros dados confidenciais.

Identificar as exceções

Utilize um tratamento de exceções estruturado e identifique condições de exceção. Isso evita que o aplicativo fique com um estado inconsistente que pode resulta na divulgação de informações. Isso também pode ajudar a proteger o aplicativo contra ataques de negação de serviço. Decida como propagar as exceções internamente no aplicativo e dê atenção especial a o que ocorre no limite do aplicativo.

Auditoria e log

Você deve executar atividades de auditoria e log nas camadas do aplicativo. Utilizando logs, é possível detectar atividades suspeitas. Elas freqüentemente indicam com antecedência um ataque devastador e os logs ajudam a resolver o risco de recusa quando os usuários recusam suas ações. Os arquivos de log podem ser exigidos em processos judiciais para provarem a transgressão dos acusados. Geralmente, o processo de auditoria é considerado mais autorizado se as auditorias forem geradas no momento exato em que um recurso é acessado e pelas mesmas rotinas que acessam o recurso.

As práticas a seguir aumentam a segurança do aplicativo da Web:

• Auditar e registrar em log o acesso entre as camadas do aplicativo.
• Considerar o fluxo de identificação.
• Registrar em log eventos importantes.
• Proteger arquivos de log.
• Fazer backup dos arquivos de log e os analisar regularmente.

Auditar e registrar em log o acesso entre as camadas do aplicativo

Audite e registre em log o acesso entre as camadas do aplicativo no caso de não–repúdio. Use uma combinação de log no nível do aplicativo e recursos de auditoria da plataforma, como a auditoria do Windows, do IIS e do SQL Server.

Considerar o fluxo de identificação

Considere como o aplicativo transmitirá a identificação do chamador entre as várias camadas do aplicativo. Você tem duas opções básicas. Você pode transmitir a identificação do chamador no nível do sistema operacional utilizando a delegação do protocolo Kerberos. Isso permite o uso da auditoria no nível do sistema operacional. A desvantagem dessa abordagem é que ela afeta a escalabilidade, pois significa que não pode haver nenhum pool de conexão do banco de dados ativo na camada intermediária. Como alternativa, você pode transmitir a identificação do chamador no nível do aplicativo e utilizar identificações confiáveis para acessar recursos de back–end. Com essa abordagem, você tem que confiar na camada intermediária e existe um risco de recuso. Você deve gerar faixas de auditoria na camada intermediária que possam ser correlacionadas às faixas de auditoria de back–end. Para isso, você deve certificar–se de que os relógios dos servidores estão sincronizados, embora o Microsoft Windows 2000 e o Active Directory façam isso por você.

Registrar em log eventos importantes

Os tipos de eventos que devem ser registrados incluem tentativas de logon bem–sucedidas ou não, modificação de dados, recuperação de dados, comunicações de rede e funções administrativas, como ativar ou desativar o registro em log. Os logs devem inclui a hora do evento, a localização do evento incluindo o nome da máquina, a identificação do usuário atual, a identificação do processo que iniciou o evento e uma descrição detalhada do evento.

Proteger arquivos de log

Proteja os arquivos de log utilizando as listas de controle de acesso do Windows e restrinja o acesso a eles. Isso dificulta para os invasores a alteração dos arquivos de log para encobrir seus rastros. Reduza o número de pessoas que podem manipular os arquivos de log. Autorize acesso somente a contas altamente confiáveis, como as dos administradores.

Fazer backup dos arquivos de log e os analisar regularmente

Não há porquê criar um log se os arquivos de log nunca são analisados. Os arquivos de log devem ser removidos dos servidores de produção regularmente. A freqüência de remoção depende do nível de atividade do aplicativo. O projeto deve considerar o modo como os arquivos de log serão recuperados e movidos para servidores offline para análise. Quaisquer protocolos e portas adicionais abertos no servidor Web com essa finalidade devem ser fechados de forma segura.

Diretrizes de projeto do aplicativo

Categoria Diretrizes

Validação da entrada Não confiar na entrada; considerar a validação da entrada centralizada.

Não confiar na validação do lado do cliente. Ter cuidado com questões de canonização. Restringir, rejeitar e limpar a entrada. Validar dados por tipo, tamanho, formato e intervalo.

Autenticação Dividir o site nas áreas de acesso anônimo, identificado e autenticado. Utilizar senhas de alta segurança. Oferecer suporte para senhas com validade e desativação de conta. Não armazenar credenciais (utilizar hashes unidirecionais com valores falsos). Criptografar os canais de comunicação para proteger os identificadores de autenticação.
Transmitir cookies de autenticação de formulários somente por conexões HTTPS.

Autorização Utilizar contas com a menor quantidade de privilégios. Considerar a granulação da autorização.

Aplicar a separação de privilégios. Restringir o acesso do usuário a recursos no nível do sistema.

Gerenciamento de configuração Utilizar contas com processos e serviços com a menor quantidade de privilégios. Não armazenar credenciais em texto sem formatação. Utilizar autenticação e autorização rígidas nas interfaces administrativas.

Não utilizar a LSA. Proteger o canal de comunicação para administração remota. Evitar armazenar dados confidenciais no espaço da Web.

Dados confidenciais Evitar armazenar segredos. Criptografar dados confidencias transmitidos. Proteger o canal de comunicação. Fornecer controles de acesso rígidos aos armazenamentos de dados confidenciais. Não armazenar dados confidenciais em cookies persistentes. Não transmitir dados confidenciais utilizando o protocolo HTTP–GET.

Gerenciamento de sessão Limitar a duração da sessão. Proteger o canal. Criptografar o conteúdo dos cookies de autenticação. Proteger o estado da sessão contra acesso não autorizado.

Criptografia Não desenvolver sua própria criptografia. Utilizar recursos da plataforma testados. Manter dados descriptografados próximos do algoritmo. Utilizar o algoritmo e o tamanho de chave corretos. Evitar o gerenciamento de chaves (utilizar DPAPI). Mudar as chaves periodicamente. Armazenar chaves em um local restrito.

Manipulação de parâmetros Criptografar o estado de cookies confidenciais. Não confiar nos campos que o cliente pode manipular (seqüências de caracteres de consulta, campos de formulário, cookies ou cabeçalhos HTTP). Validar todos os
valores enviados a partir do cliente.

Gerenciamento de exceções Utilizar um tratamento de exceções estruturado. Não revelar detalhes confidenciais da implementação do aplicativo. Não registrar em log dados particulares, como senhas. Considerar uma estrutura de gerenciamento de exceções centralizado.

Auditoria e log Identificar comportamento mal–intencionado. Saber como é um tráfego normal. Executar atividades de auditoria e log em todas as camadas do aplicativo. Proteger o acesso aos arquivos de log. Fazer backup dos arquivos de log e os analisar regularmente.

A segurança deve difundir–se por todos os estágios do ciclo de desenvolvimento do produto e deve ser um dos pontos principais do projeto do aplicativo. Preste atenção, especialmente, ao projeto de uma estratégia rígida de autenticação e autorização. Lembre–se também de que a maioria dos ataques no nível do aplicativo utiliza dados com entrada mal–intencionada e uma validação fraca da entrada do aplicativo. As instruções apresentadas neste módulo ajudarão você com esses e outros aspectos complicados referentes ao projeto e à criação de aplicativos seguros.

fonte:msdn,MXStudio

Live Mesh Beta

Publicado em 21/04/201025/10/2010 por homdigitalis

What’s inside Live Mesh?

Some features are not available for all countries/regions.

Devices page

Manage your mesh here. Click Add Device to download and install the Live Mesh software on your computer, so you can automatically sync your folders with other computers in your mesh and with your Live Desktop. You can also connect to a remote computer or your Live Desktop from here. To access the page, click Devices in your Live Desktop header bar.

Live Desktop

Your Windows PC on the web—complete with 5 GB of free storage space—where you can see all your synchronized folders in one place. It lives on the web, which means that even if you‘re not at one of your computers, you can still access and work with your folders from any computer that‘s connected to the Internet.

Mesh bar

Appears whenever you open a folder in your mesh, helping you manage your files and the members you invite to share them. Use the mesh bar to:

Invite or manage members
See who has access to the folder
See news related to the folder
Post messages to the folder
Chat with members using Windows Live Messenger*
Change synchronization settings for the folder

* Windows-only feature

Notifier

Looking for a snapshot of your mesh? The notifier lets you see news about what’s happening in your mesh and quickly check the status of all your synchronized folders and devices. It stays out of your way while you work, but is always available by clicking the Live Mesh icon in the notification area of your Windows taskbar, the menu bar of your Mac, or the taskbar of your Live Desktop.

News

Available from the notifier, the mesh bar, and your Live Desktop, Live Mesh News gives you a continuous feed detailing activities in your mesh. It lets you know when a file in a shared folder has been changed, when someone joins or leaves a folder you’re sharing, when messages are posted to folders, and more.

Live Mesh Remote Desktop*

Transport yourself to another computer in your mesh. Live Mesh Remote Desktop opens a window into your remote computer and gives you access to even those folders you haven’t synchronized. You can also use any programs on your remote computer, even if you don’t have them installed on your local computer.

Copy and paste files between your remote computer and your local computer, and even connect from almost any web browser.

* Windows-only feature

Mac*

Add a Mac to your mesh. Sync and share folders between your PC and your Mac. Or your friend’s Mac. Or between two Macs. Live Mesh gives you cross-platform functionality, so you can maximize your mesh.

* Some Live Mesh features not yet available for the Mac

Mobile*

Take your mesh with you wherever you go. From any mobile phone with web access, go to mesh.com to work with your synchronized folders, upload photos to share with others, read news about your mesh, and more.

* Some mobile phones not compatible with certain Live Mesh features

Are you a developer?

The mesh is more than what you see today. Be among the first to see what’s under the hood and use our SDK to build mesh applications. Learn more about the Developer Program.

YouTube video duration, Word forms & mouse wheel on browser

Publicado em 21/04/201016/09/2015 por homdigitalis

Ora cá vão três dicas porreiras de Informática:

YouTube

1º – certas vezes podemos querer enviar um link de um vídeo do YouTube a alguém. Mas apenas queremos que esse alguém veja o que acontece aos 18 segundos de vídeo. Ora basta copiar o endereço do vídeo do YouTube e acrescentar ao link, os minutos pretendidos.

Exemplo:

http://www.youtube.com/watch?v=7WtkD9kXZJQ&feature=grec&playnext_from=TL&videos=YASKIVC9aQM&playnext=1#t=00m18s

Acabou-se a seca da pessoa ter de esperar que o vídeo chegue à parte desejada!

Word Forms

2º – Querem fazer uma selecção à medida no Word? Experimente clicar na tecla Alt e seleccionar com o rato o que deseja. Já agora, se pretende elaborar formulários no Word, visite o seguinte link: http://office.microsoft.com/en-us/word/HA100307461033.aspx#1

Mouse Wheel

3º – Sabiam que se clicarmos naquela rodinha do rato, sobre uma hiperligação, ela abrirá num novo separador? Ora mais uma utilidade sem ser o scroll para a famosa rodinha do rato!

Memória: preço vs frequência

Publicado em 14/04/201016/09/2015 por homdigitalis

Até que ponto vale a pena pagar mais por memória de maior frequência?

A maioria dos PC’s disponíveis nas lojas vem equipada com módulos de memória com frequências consideradas padrão, normalmente 800 Mhz para DDR2 e 1066 ou 1333 Mhz para DDR3.

No entanto, as lojas da especialidade estão cheias de módulos bem mais rápidos. Infelizmente, os Mhz extras custam muitos euros. Na verdade, facilmente módulos rotulados de elevado desempenho podem custar o dobro ou mesmo mais do que os módulos de frequências base.

A confusão dos MHZ

A frequência define o número de ciclos por segundo. Esta é a regra. No entanto, desde que surgiu o DDR (Double Data Rate), que a frequência real do hardware é diferente da frequência aparente. Por exemplo, um módulo de DDR2-800 é, para simplificar, rotulado de 800 Mhz. Na verdade, a frequência real dos chips de memória é de apenas 200 Mhz, enquanto o bus de comunicação é de 400 Mhz (ligação entre a memória e o CPU ou chipset). Mas devido às tecnologias utilizadas, em termos práticos, o número de operações por segundo de um módulo DDR2-800 é equivalente a um hipotético módulo SDRAM a 800 Mhz.

Depois de feitos os cálculos, a escolha de memória com frequência mais elevada conduz a um claro aumento de desempenho. No entanto, a velocidade de transferência máxima está muito longe de ser o único factor para definir o desempenho de um computador. Por exemplo, não é por termos memória de maior frequência que o disco rígido ou a placa gráfica se vão tornar mais eficientes. Por outro lado, a memória mais rápida permite trocas de dados mais céleres entre o CPU e a RAM. Não é tudo, mas é uma vantagem importante, sobretudo em aplicações que estão constantemente a trocar dados com a RAM.

Na verdade, a velocidade de transferência máxima nem sequer é o único factor para definir a eficiência de trocas de dados entre o CPU e a RAM. Há outros factores, onde sobressaem a latência (tempos de acesso à memória) e a relação de frequência bus/CPU/RAM.

A latência, normalmente medida em ciclos de relógio, define o tempo de espera do CPU para que o acesso à memória seja completo. Se se disser, por exemplo, que determinada latência é de quatro ciclos de relógio, isto significa que são perdidos quatro ciclos até o acesso à memória ficar completo.

Imagine, por exemplo, que um grupo de pessoas está à espera de entrar numa casa. A latência pode ser vista como o tempo entre o momento em que alguém do grupo tocou à campainha e o momento em que a porta foi aberta.

A velocidade de transferência, por outro lado, é dada pela velocidade a que as pessoas se deslocam e pelo número de pessoas que podem entrar em simultâneo (largura da porta). Ou seja, no limite, se a latência for muito alta (demora-se uma eternidade a abrir a porta), pouco importa a velocidade de transferência. O problema é que a latência tende a ser maior quanto maior é a frequência da memória, o que limita as vantagens de se utilizar módulos mais rápidos. Tudo depende das aplicações que utilizamos, já que algumas trocam muitas vezes dados pequenos e outras trocam grandes quantidades de dados, mas menos vezes. As primeiras tendem a ser beneficiadas com latências baixas, enquanto as segundas ganham mais com a frequência extra.

Resultados e conclusões

Afinal, vale ou não vale a pena adquirir memória mais rápida? Depende da utilização que dá ao computador. Se corre, sobretudo jogos, verifica-se que a frequência dos módulos influi muito pouco nos resultados. É preferível gastar o dinheiro extra numa placa gráfica mais poderosa.

Em tarefas de produtividade, o aumento de desempenho até pode ser visível nos benchmarks, mas não se sente na prática. Pelo menos, não de modo a justificar o investimento extra.

Onde os módulos de memória mais rápidos “brilham” é nas aplicações ditas de criatividade. Os programas de edição de imagem, de vídeo e de criação de conteúdos multimédia ganham eficiência. De modo que podemos considerar substancial – veja-se como o render de vídeo HD no Movie Maker foi 20 segundos mais rápido quando a utilizar memória DDR3 a 1600 MHz. A razão é simples: estas aplicações trabalham normalmente com ficheiros “pesados”.

Future of the Web

Publicado em 13/04/201025/10/2010 por homdigitalis

The future of the Web is everywhere. The future of the Web is not at your desk. It’s not necessarily in your pocket, either. It’s everywhere. With each new technological innovation, we continue to become more and more immersed in the Web, connecting the ever-growing layer of information in the virtual world to the real one around us. But rather than get starry-eyed with utopian wonder about this bright future ahead, we should soberly anticipate the massive amount of planning and design work it will require of designers, developers and others.

The gap between technological innovation and its integration in our daily lives is shrinking at a rate much faster than we can keep pace with—consider the number of unique Web applications you signed up for in the past year alone. This has resulted in a very fragmented experience of the Web. While running several different browsers, with all sorts of plug-ins, you might also be running multiple standalone applications to manage feeds, social media accounts and music playlists.

Even though we may be adept at switching from one tab or window to another, we should be working towards a more holistic Web experience, one that seamlessly integrates all of the functionality we need in the simplest and most contextual way. With this in mind, let’s review four trends that designers and developers would be wise to observe and integrate into their work so as to pave the way for a more holistic Web browsing experience:

The browser as operating system,
Functionally-limited mobile applications,
Web-enhanced devices,
Personalization.

[By the way: The network tab (on the top of the page) is updated several times a day. It features manually selected articles from the best web design blogs!]

1. The Browser As Operating System

Thanks to the massive growth of Web productivity applications, creative tools and entertainment options, we are spending more time in the browser than ever before. The more time we spend there, the less we make use of the many tools in the larger operating system that actually runs the browser. As a result, we’re beginning to expect the same high level of reliability and sophistication in our Web experience that we get from our operating system.

For the most part, our expectations have been met by such innovations as Google’s Gmail, Talk, Calendar and Docs applications, which all offer varying degrees of integration with one another, and online image editing tools like Picnik and Adobe’s online version of Photoshop. And those expectations will continue to be met by upcoming releases, such as the Chrome operating system—we’re already thinking of our browsers as operating systems. Doing everything on the Web was once a pipe dream, but now it’s a reality.

Ubiquity

The one limitation of Web browsers that becomes more and more obvious as we make greater use of applications in the cloud is the lack of usable connections between open tabs. Most users have grown accustomed to keeping many tabs open, switching back and forth rapidly between Gmail, Google Calendar, Google Docs and various social media tools. But this switching from tab to tab is indicative of broken connections between applications that really ought to be integrated.

Mozilla is attempting to functionally connect tools that we use in the browser in a more intuitive and rich way with Ubiquity. While it’s definitely a step in the right direction, the command-line approach may be a barrier to entry for those unable to let go of the mouse. In the screenshot below, you can see how Ubiquity allows you to quickly map a location shown on a Web page without having to open Google Maps in another tab. This is one example of integrated functionality without which you would be required to copy and paste text from one tab to another. Ubiquity’s core capability, which is creating a holistic browsing experience by understanding basic commands and executing them using appropriate Web applications, is certainly the direction in which the browser is heading.

This approach, wedded to voice-recognition software, may be how we all navigate the Web in the next decade, or sooner: hands-free.

Tracemonkey and Ogg

Meanwhile, smaller, quieter releases have been paving the way to holistic browsing. This past summer, Firefox released an update to its software that includes a brand new JavaScript engine called TraceMonkey. This engine delivers a significant boost in speed and image-editing functionality, as well as the ability to play videos without third-party software or codecs.

Aside from the speed advances, which are always welcome, the image and video capabilities are perfect examples of how the browser is encroaching on the operating system’s territory. Being able to edit images in the browser could replace the need for local image-editing software on your machine, and potentially for separate applications such as Picnik. At this point, it’s not certain how sophisticated this functionality can be, and so designers and ordinary users will probably continue to run local copies of Photoshop for some time to come.

The new video functionality, which relies on an open-source codec called Ogg, opens up many possibilities, the first one being for developers who do not want to license codecs. Currently, developers are required to license a codec if they want their videos to be playable in proprietary software such as Adobe Flash. Ogg allows video to be played back in Firefox itself.

What excites many, though, is that the new version of Firefox enables interactivity between multiple applications on the same page. One potential application of this technology, as illustrated in the image above, is allowing users to click objects in a video to get additional information about them while the video is playing.

2. Functionally-Limited Mobile Applications

So far, our look at a holistic Web experience has been limited to the traditional browser. But we’re also interacting with the Web more and more on mobile devices. Right now, casual surfing on a mobile device is not a very sophisticated experiences and therefore probably not the main draw for users. The combination of small screens, inconsistent input options, slow connections and lack of content optimized for mobile browsers makes this a pretty clumsy, unpredictable and frustrating experience, especially if you’re not on an iPhone.

However, applications written specifically for mobile environments and that deal with particular, limited sets of data—such as Google’s mobile apps, device-specific applications for Twitter and Facebook and the millions of applications in the iPhone App Store—look more like the future of mobile Web use. Because the mobile browsing experience is in its infancy, here is some advice on designing mobile experiences: rather than squeezing full-sized Web applications (i.e. ones optimized for desktops and laptops) into the pocket, designers and developers should become proficient at identifying and executing limited functionality sets for mobile applications.

Amazon Mobile

A great example of a functionally-limited mobile application is Amazon’s interface for the iPhone (screenshot above). Amazon has reduced the massive scale of its website to the most essential functions: search, shopping cart and lists. And it has optimized the layout specifically for the iPhone’s smaller screen.

Facebook for iPhone

Facebook continues to improve its mobile version. The latest version includes a simplified landing screen, with an icon for every major function of the website in order of priority of use. While information has been reduced and segmented, the scope of the website has not been significantly altered. Each new update brings the app closer to replicating the full experience in a way that feels quite natural.

Gmail for iPhone

Finally, Gmail’s iPhone application is also impressive. Google has introduced a floating bar to the interface that allows users to batch process emails, so that they don’t have to open each email in order to deal with it.

3. Web-Enhanced Devices

Mobile devices will proliferate faster than anything the computer industry has seen before, thereby exploding entry points to the Web. But the Web will vastly expand not solely through personal mobile devices but through completely new Web-enhanced interfaces in transportation vehicles, homes, clothing and other products.

In some cases, Web enhancement may lend itself to marketing initiatives and advertising; in other cases, connecting certain devices to the Web will make them more useful and efficient. Here are three examples of Web-enhanced products or services that we may all be using in the coming years:

Web-Enhanced Grocery Shopping

Web-connected grocery store “VIP” cards may track customer spending as they do today: every time you scan your customer card, your purchases are added to a massive database that grocery stores use to guide their stocking choices. In exchange for your data, the stores offer you discounts on selected products. Soon with Web-enhanced shopping, stores will be able to offer you specific promotions based on your particular purchasing history, and in real time (as illustrated above). This will give shoppers more incentive to sign up for VIP programs and give retailers more flexibility and variety with discounts, sales and other promotions.

Web-Enhanced Utilities

One example of a Web-enhanced device we may all see in our homes soon enough is a smart thermostat (illustrated above), which will allow users not only to monitor their power usage using Google PowerMeter but to see their current charges when it matters to them (e.g. when they’re turning up the heater, not sitting in front of a computer).

Web-Enhanced Personal Banking

Another useful Web enhancement would be a display of your current bank account balance directly on your debit or credit card (as shown above). This data would, of course, be protected and displayed only after you clear a biometric security system that reads your fingerprint directly on the card. Admittedly, this idea is rife with privacy and security implications, but something like this will nevertheless likely exist in the not-too-distant future.

4. Personalization

Thanks to the rapid adoption of social networking websites, people have become comfortable with more personalized experiences online. Being greeted by name and offered content or search results based on their browsing history not only is common now but makes the Web more appealing to many. The next step is to increase the user’s control of their personal information and to offer more tools that deliver new information tailored to them.

Centralized Profiles

If you’re like most people, you probably maintain somewhere between two to six active profiles on various social networks. Each profile contains a set of information about you, and the overlap varies. You probably have unique usernames and passwords for each one, too, though using a single sign-on service to gain access to multiple accounts is becoming more common. But why shouldn’t the information you submit to these accounts follow the same approach? In the coming years, what you tell people about yourself online will be more and more under your control. This process starts with centralizing your data in one profile, which will then share bits of it with other profiles. This way, if your information changes, you’ll have to update your profile only once.

Data Ownership

The question of who owns the data that you share online is fuzzy. In many cases, it even remains unaddressed. However, as privacy settings on social networks become more and more complex, users are becoming increasingly concerned about data ownership. In particular, the question of who owns the images, video and messages created by users becomes significant when a user wants to remove their profile. To put it in perspective, Royal Pingdom, in its Internet 2009 in Numbers report, found that 2.5 billion photos were uploaded to Facebook each month in 2009! The more this number grows, the more users will be concerned about what happens to the content they transfer from their machines to servers in the cloud.

While it may seem like a step backward, a movement to restore user data storage to personal machines, which would then intelligently share that data with various social networks and other websites, will likely spring up in response to growing privacy concerns. A system like this would allow individuals to assign meta data to files on their computers, such as video clips and photos; this meta data would specify the files’ availability to social network profiles and other websites. Rather than uploading a copy of an image from your computer to Flickr, you would give Flickr access to certain files that remain on your machine. Organizations such as the Data Portability Project are introducing this kind of thinking accross the Web today.

Recommendation Engines

Search engines—and the whole concept of search itself—will remain in flux as personalization becomes more commonplace. Currently, the major search engines are adapting to this by offering different takes on personalized search results, based on user-specific browsing history. If you are signed in to your Google account and search for a pizza parlor, you will more likely see local results. With its social search experiment, Google also hopes to leverage your social network connections to deliver results from people you already know. Rounding those out with real-time search results gives users a more personal search experience that is a much more realistic representation of the rapid proliferation of new information on the Web. And because the results are filtered based on your behavior and preferences, the search engine will continue to “learn” more about you in order to provide the most useful information.

Another new search engine is attempting to get to the heart of personalized results. Hunch provides customized recommendations of information based on users’ answers to a set of questions for each query. The more you use it, the better the engine gets at recommending information. As long as you maintain a profile with Hunch, you will get increasingly satisfactory answers to general questions like, “Where should I go on vacation?”

The trend of personalization will have significant impact on the way individual websites and applications are designed. Today, consumer websites routinely alter their landing pages based on the location of the user. Tomorrow, websites might do similar interface customizations for individual users. Designers and developers will need to plan for such visual and structural versatility to stay on the cutting edge.

Conclusion

Each of these trends—browser operating systems, mobile, Web-enhanced devices and personalization—provides a foundation for the other. First, traditional browsers will continue to expand their functional scope to meet our demands, ideally in a way that simplifies the user experience rather than just by adding more tabs or toolbars. But our demands will ultimately drive mobile innovation as well, expanding points of entry to the Web far beyond our desks.

As people grow accustomed to being able to access the Web from anywhere, the next logical step will be to create unique entry points, specific to context and purpose and crafted especially for us. This final stage will be truly transformative, imbuing our daily lives with a rich layer of uniquely targeted information that will make us more efficient and effective in what we do. But reaching every step along the way will fully depend on the vision of designers and developers to refine existing interfaces and create completely new ones.

To Sum Up

Web browsers will continue to be refined and expanded to include new functionality that will approach an operating system’s level of sophistication.
Designers and developers need to become proficient at identifying and executing functionally limited sets for mobile applications.
Previously unconnected objects will be enhanced with filters to send and receive contextual data across the Web. The design of these objects will change as a result of new interface attributes.
Personalization trends will give users more control over their information and bring new, relevant information to them.

Further Resources

(al)

Autor: homdigitalis

Facebook

Twitter

MySpace

LinkedIn

Google

Ebay

Wikipedia

Flickr/Yahoo!

Windows Live

Stumbleupon

WordPress.com

Amazon

YouTube

PayPal

Why’s It So Complicated?

Account Deletion Remorse

Should You Use Complicated Account Deletion Processes?

What’s inside Live Mesh?

Devices page

Live Desktop

Mesh bar

Notifier

News

Live Mesh Remote Desktop*

Mac*

Mobile*

Are you a developer?

YouTube

Word Forms

Mouse Wheel

Até que ponto vale a pena pagar mais por memória de maior frequência?

A confusão dos MHZ

Resultados e conclusões

1. The Browser As Operating System

Ubiquity

Tracemonkey and Ogg

2. Functionally-Limited Mobile Applications

Amazon Mobile

Facebook for iPhone

Gmail for iPhone

3. Web-Enhanced Devices

Web-Enhanced Grocery Shopping

Web-Enhanced Utilities

Web-Enhanced Personal Banking

4. Personalization

Centralized Profiles

Data Ownership

Recommendation Engines

Conclusion

To Sum Up

Further Resources