Category: Articles & Lectures

Oportunidades de Aplicação de Big Data em Saúde: Os Clientes e Os Pesquisadores

Posted by – 21/11/2016

Nos posts anteriores dessa série, listamos os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde e passamos a analisar as oportunidades de aplicação de Big Data para cada um deles. Concluiremos agora essa série examinando as oportunidades que se apresentam para os Clientes e passando rapidamente por oportunidades para os Pesquisadores.

Os Clientes das organizações de saúde podem ter sua vida bastante facilitada pelos mecanismos de Big Data adotados pelos demais atores. É muito frequente que consultas sejam marcadas para uma data futura contando com a disponibilidade de resultados de exames na tal data. Essas consultas ou são inefetivas ou tornam-se simplesmente uma ausência a mais caso esse exame não esteja disponível. E isso acontece com imagem, com laboratório, com patologia e praticamente com qualquer área de apoio. Ao detectar que um determinado resultado não estará disponível, medidas podem ser tomadas para remarcar a consulta, por exemplo.

Isso é especialmente importante em hospitais terciários, que atendem muitas pessoas que não fazem parte da população local que muitas vezes enfrentaram longos deslocamentos apenas para ver sua intenção malograda pela indisponibilidade de algum dado.

Além disso, ao detectar que um perfil específico de Cliente tem uma necessidade (por exemplo, realização de coletas fora do horário comercial), o sistema pode reorganizar as demais coletas para acomodar aquele perfil, de uma maneira dinâmica, evitando que o Cliente procure outro serviço que tenha a disponibilidade de que necessita.

Propositalmente, não entraremos em detalhes dos benefícios para a população dos Pesquisadores, uma vez que acredito que sejam auto-evidentes: a disponibilidade de dados em múltiplos sistemas e a possibilidade de filtragem uma vez que esses dados estejam disponíveis permite que toda sorte de pesquisa científica seja realizada. Existem grupos coletando dados de pacientes de UTI e alertando para sepse; existem grupos de pesquisa de transplantes alertando para pacientes que desenvolverão rejeição meses antes que ela seja evidente; existem grupos que previnem a re-internação baseado na coleta remota de dados simples.

As possibilidades realmente são muito amplas e a tecnologia permite uma gama de combinações que cientistas de dados podem fazer que simplesmente não tem como ser antecipada.

Oportunidades de Aplicação de Big Data em Saúde: Os Pagadores

Posted by – 14/11/2016

Nos posts anteriores dessa série, listamos os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde e passamos a analisar as oportunidades de aplicação de Big Data para cada um deles. Nesse post analisaremos rapidamente as oportunidades que se apresentam para os Pagadores.

A penúltima população que analisamos, os Pagadores, põem-se, muitas vezes, como antagonistas dos Provedores e negam pagamentos a procedimentos já realizados de uma forma rotineira. Mas isso não precisa ser assim.

Quantas auditorias poderiam ser evitadas e quanto tempo perdido poderia ser recuperado caso as informações que fizeram um determinado procedimento ser necessário estivessem a disposição dos Pagadores no momento em que se decide por uma glosa? Ou mesmo, quantos procedimentos repetidos em diversos serviços poderiam ser evitados caso os dados compartilhados de um estivesse disponíveis para outro? Sim… estamos longe disso, mas os primeiros passos já podem ser dados agora e muita coisa pode ser feita em parceria. Nem os Provedores se beneficiam de um Pagador falido, nem os Pagadores se beneficiam de um Provedor ineficiente. Essa posição de antagonismo não precisa ser a regra.

Além disso, uma disciplina bem desenvolvida dentro do Big Data, com algoritmos bem reconhecidos e estudados e com bastante experiência acumulada é o controle de fraudes. Todo esse expertise pode ser importado por um cluster de Big Data a serviço dos Pagadores e, em paralelo com os controles hoje existentes, pode auxiliar na detecção de atividades fraudulentas, constituindo mais uma ferramenta.

Por fim, um diferencial importante para qualquer Pagador é a agilidade com que consultas e procedimentos são autorizados. Com os dados disponíveis e devidamente analisados em tempo real, esse diferencial se transforma em vantagem para seus clientes o que, em última instância, se transforma em receita.

No próximo, e último, post, analisaremos o que se espera de oportunidades do Big Data para os Clientes.

Oportunidades de Aplicação de Big Data em Saúde: A Força de Trabalho

Posted by – 07/11/2016

Nos posts anteriores dessa série, listamos os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde e comecei a analisar as oportunidades de aplicação de Big Data para cada um deles, começando com os Provedores. Nesse post analisaremos rapidamente as oportunidades que se apresentam para outro grupo, a Força de Trabalho.

Existem diversas oportunidades que se referem a características básicas do Big Data, especialmente ao seu potencial agregador e pervasivo que podem ser aplicadas pelos e para a Força de Trabalho. Vamos tomar um médico como representante dessa categoria e vejamos, por exemplo, seu fluxo usual em um hipotético round (“round” é como tratamos, em nosso meio, a visita em série aos pacientes internados sob responsabilidade de um médico ou de uma determinada equipe):

  • O médico visita o paciente em seu leito, coleta as informações subjetivas do mesmo, atualiza um ou outro conhecimento a cerca da evolução de sua doença e volta para a sala de prescrição;

  • Na sala de prescrição ele abre o sistema 1 para verificar os últimos exames de laboratório do paciente;

  • A seguir ele abre o sistema 2 para verificar as últimas imagens e/ou seus relatórios;

  • Ato contínuo ele abre o sistema 3 para verificar se o resultado de um procedimento (por exemplo, um exame de patologia) retornou e, caso positivo, qual seu resultado;

  • De posse desse conhecimento, ele abre o sistema de prontuário eletrônico para registrar sua visita e para prescrever os próximos passos ou a continuidade do cuidado;

  • Finalmente o médico retorna para a enfermaria para visitar o paciente ao lado.

Com algumas variações e com a utilização de notas à beira do leito, os médicos podem otimizar essa rotina, por exemplo, visitando a todos e depois se retirando para “lidar” com os diversos sistemas. Dificilmente, no entanto, vão escapar de interagir com sistemas diferentes e utilizar seu bom senso para integrar os conhecimentos neles contidos. Uma perda de termpo e eficiência injustificada. Sem falar que é fácil negligenciar um desses passos (por exemplo, ao invés de verificar o sistema de patologia por algum resultado adiantado, o médico escolhe esperar os X dias que usualmente são consumidos na análise de uma peça anatômica e perde a oportunidade de tomar uma atitude assim que a informação estiver disponível).

Ora! Tecnologia para agregar todas as informações de diferentes sistemas está disponível há muitos anos e o Big Data não só a tornou acessível como eficiente. E se o médico tiver todas essas informações na mão? Suponha em um tablet ou outro dispositivo de visualização, com uma interface de busca estilo Google, ou mesmo algo mais estruturado, que aglutine todas as informações relevantes ao alcance de um toque. Ao invés de páginas e páginas de exames laboratoriais, gráficos gerados “just-in-time” com a evolução de todos os exames relevantes e com codificação de cores para indicar os que estejam fora do padrão. Da mesma forma que as notificações para os Gerentes Assistenciais, exames que saiam do padrão podem gerar alertas personalizados, que os médicos podem receber em sua interface de trabalho ou em outro dispositivo.

Outra prática onde a agregação que o Big Data é capaz de proporcionar pode ajudar essa população é a interação entre as disciplinas. O mesmo sistema de notificação pode ser utilizado para avisar de interconsultas ou pedidos de consultoria para outras especialidades. Muitos grupos fazem isso utilizando ferramentas públicas, como WhatsApp, ou celulares dedicados a grupos (como o “celular da cirugia”), mas veja que é muito mais fácil e efetivo criar uma notificação no sistema do que entrar em contato com alguém em uma ferramenta terceira e passar um caso para consultoria (ao que o destinatário poderia ter acesso completo e não a apenas uma fração). Ademais, a agregação desses metadados pode ajudar a gerar outros insights: por exemplo, pacientes que têm mais de duas consultorias solicitadas têm prognóstico mais reservado? Ou equipes que têm muitas solicitações de interconsultas têm o número de profissionais adequado?

Áreas de apoio, como patologia e SADTs também se beneficiam. Veja que a rotina intensa de trabalho (fruto da necessidade de produzir resultados cada vez mais rápido) nessas áreas leva muitas vezes a que seus trabalhadores negligenciem as informações que estão disponíveis em outro sistema e se restrinjam aos pequenos bits de informação contidas em uma papeleta que podem ou não ser relevantes e podem ou não ser completos. A qualidade do resultado cai e aumenta muito a chance de erros ou intervenções desnecessárias.

Veja que examinamos majoritariamente o caso do médico, mas praticamente toda a Força de Trabalho assistencial está em maior ou menor grau submetida a isso. Fisioterapeutas, psicólogos, assistentes sociais, todos têm rotinas parecidas e se beneficiariam dos mesmos tipos de ferramentas.

No próximo post, analisaremos o que se espera de oportunidades do Big Data para os Pagadores.

Oportunidades de Aplicação de Big Data em Saúde: Os Gerentes Assistenciais

Posted by – 31/10/2016

No primeiro post dessa série, listei os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde, seja ela um hospital ou uma clínica. Quais sejam, os Provedores, a Força de Trabalho, os Pesquisadores, os Pagadores e os Clientes. No post seguinte, analisei brevemente a primeira subpopulação dos Provedores, que é composta pelos Administradores Hospitalares. Nesse post analisaremos rapidamente as oportunidades que se apresentam para outra subpopulação deles: os Gerentes Assistenciais.

Os Gerentes Assistenciais recebem dados que permitem uma tomada de decisão “local” e em pequena escala, sem a necessidade de um processo burocrático na instância superior e que provavelmente servirá para o “melhor cenário” e não contemplará uma miríade de cenários sub-ótimos que são bastante mais frequentes.

Uma das perguntas que pode ser respondida para essa população é: Se um determinado paciente tem a necessidade de coletar um exame específico, qual o melhor momento para fazê-lo? Em um ambiente hospitalar, um paciente que se desloca entre departamentos leva consigo um funcionário (em geral um técnico de enfermagem) que vai “desfalcar” a equipe local. Fazer esse deslocamento no momento errado pode ampliar o tempo necessário para o retorno do funcionário e gerar toda a sorte de ineficiência como consequência. Muito mais efetivo é ter uma alocação dinâmica e disparar o processo de transporte no momento ótimo.

Esses Gerentes ainda podem ter acesso a notificações de processos de que eventualmente estejam responsáveis. Ao invés de ligar para a farmácia diariamente para verificar a disponibilidade de um determinado medicamento ou material, sua interface de trabalho o notifica quando um material necessário chega à farmácia.

Dependendo do grau pretendido de integração das informações, um Gerente Assistencial pode ajudar a alimentar algoritmos de aprendizado de máquina que tornem possível a automatização de diversas tarefas, acabando com a perda de tempo com as rotinas repetitivas e com a possibilidade de que tarefas essenciais sejam esquecidas em prol do “problema da vez”.

Por fim, não podemos esquecer de um sério problema que faz parte do dia a dia dos Gerentes Assistenciais em qualquer organização de saúde de médio ou grande porte: as escalas e as capacidades de cada funcionário. Através da integração com os dados do departamento de pessoal quando da ocorrência de uma falta ou quando da programação de férias, é possível rapidamente saber qual funcionário e de onde ele vai ser deslocado para cobrir a vacância. Não é incomum que esses controles sejam feitos manualmente e executados “na emergência”, muitas vezes resultando em um deslocalmento de um funcionário sem a capacitação adequada para aquele serviço, ou na criação de um novo problema em solução ao anterior. Com a integração desses dados na interface de trabalho dos Gerentes Assistenciais, resolver esses problemas se torna trivial.

No próximo post, analisaremos o que se espera de oportunidades do Big Data para a Força de Trabalho.

Oportunidades de Aplicação de Big Data em Saúde: Os Administradores Hospitalares

Posted by – 24/10/2016

No primeiro post dessa série, listei os atores e os beneficiários de uma estratégia de Big Data dentro de uma organização de saúde, seja ela um hospital ou uma clínica. Quais sejam, os Provedores, a Força de Trabalho, os Pesquisadores, os Pagadores e os Clientes. Nesse post analisaremos rapidamente as oportunidades que se apresentam para os Provedores, especialmente para uma subpopulação deles: os Administradores Hospitalares.

Os Administradores Hospitalares devem primar pela prestação de serviços com a melhor qualidade possível dentro do orçamento proposto. Clínicas e hospitais em geral têm departamentos para cuidar da relação com fornecedores e da qualidade de suas compras e embora o Big Data possa ter algum papel aqui, esse já é um caso coberto por ferramentas tradicionais e com processos provavelmente mais bem definidos e aceitos dentro das instituições. Há um papel paralelo para o Big Data nesse caso, quando não houver interesse de fazê-lo protagonista, mas analiso esse caso mais tarde.

Onde o Big Data brilha, nesse caso, é na gama de ferramentas que disponibiliza para avaliação e tomada de decisão em tempo quase real. Um cluster de Big Data pode, por exemplo, através do consumo de dados on-line dos prontuários eletrônicos e de outros sistemas com base no paciente (por exemplo, farmácia), apontar qual o paciente é um potencial risco econômico (pacientes que, por causa do perfil da doença, do tipo do seguro-saúde ou das interações da equipe médica com a prescrição, têm potencial para dar prejuízo ao hospital) e sugerir medidas para mitigar esse risco.

Outra oportunidade para os administradores hospitalares é a monitoração em tempo quase real da ocupação dos serviços e a sugestão, através de algoritmos de aprendizado de máquina e das redes neurais, da alocação ótima de recursos. Por exemplo, se pacientes de um determinado seguro-saúde ou convênio, com uma determinada faixa etária ou com determinados perfis preferem realizar exames de SADT em determinados horários enquanto outros perfis de paciente não têm preferência, será que não é mais custo-efetivo alocar os pacientes com expectativas mais restritas nos horários adequados do que arriscar perdê-los?

Outro exemplo é a otimização das agêndas de consultas ou de realização de exames conforme a sazonalidade ou as condições do tempo (com previsão de chuva posso fazer “overbooking” já que conto com um maior absenteísmo na nossa população?).

Além disso, as ferramentas de Business Inteligence provavelmente já em uso pelos administradores podem tanto se alimentar de dados de um cluster Big Data quando alimentá-lo, oferecendo uma convergência e uma riqueza de dados muito maior para os tomadores de decisão da organização.

Por fim, mas sem a pretenção de esgotar as oportunidades, tudo que envolve a assistência médica pode ter seu pagamento negado a posteriori. Desde internações até procedimentos e medicamentos podem ser “glosados” pelos Pagadores, deixando o Provedor com uma conta “perdida”. Existem algoritmos que empresas estadounidenses utilizam para evitar fraudes que podem ser perfeitamente adaptados para identificar quais são as contas que estão sob risco de glosa. De posse dessa informação em um momento anterior, o Provedor pode tomar medidas que mitiguem o risco econômico ou que até previnam a ocorrência da glosa.

No próximo post, analisaremos o que se espera de oportunidades do Big Data para outra subpopulação dos Provedores, os Gerentes Assistenciais.

A matemática do recrutamento ideal

Posted by – 20/10/2016

Em 2016 a Propus completará 13 anos. Como boa parte das empresas de TI, nasceu da união de amigos “micreiros”: especificamente, de amantes do software livre e do código aberto, que resolveram “colocar o dinheiro onde está nossa boca” e testar esse modelo de negócios. Muitos altos e baixos depois, algumas reformulações e passadas algumas crises econômicas, acho que finalmente chegamos a um sistema de recrutamento adequado. Ou, ao menos, o último processo seletivo que conduzi deixou-me mais satisfeito do que jamais estive antes.

Em primeiro lugar, vamos deixar claro: contratar bons funcionários é difícil. E contratar bons funcionários em uma empresa de TI é provavelmente ainda mais difícil. A Propus se orgulha de contratar hackers – afinal de contas, essa é uma empresa de hackers – logo, sabemos bem como é difícil. (Spoiler: se você é hacker, por favor, entre em contato!).

No começo nosso processo era bastante enxuto: uma troca de email e uma entrevista simples e era bastante fácil saber quem queríamos. Depois, certificações começaram a ser consideradas e, especialmente no caso de desenvolvedores, líamos os códigos escritos pelo candidato. Passamos pela fase da avaliação psicológica, da avaliação por consultoria terceirizada, até da avaliação “grafológica”! Chegamos mesmo a aplicar pequenas provas com conhecimentos básicos que precisávamos.

Em outro momento, mantivemos um programa de estágio com o objetivo expresso de contratar os que se saíssem melhor no programa. Embora essa seja uma abordagem que gostamos muito, às vezes não dá para esperar até algum estagiário “ficar pronto”, ou correr o risco de que, naquele ano em especial, nenhum estagiário tenha se saído particularmente bem para ser contratado como profissional.

Esse era um problema sem solução, usualmente abordado da maneira tradicional: anúncio em jornal e listas de discussão ou fóruns na Internet, análise de currículo e entrevista. No último processo que conduzimos dessa forma, recebemos mais de 100 currículos, dos quais cerca de 30 eram “perfeitos para a vaga”, o que gerou 30 entrevistas e… nenhuma contratação. Isso mesmo! Nenhuma das 30 entrevistas de fato se encaixava na análise prévia do currículo.

O grande problema é que o tempo investido nessa seleção e nessas 30 entrevistas foi muito grande e o resultado foi muito ruim. A experiência havia sido tão traumática que simplesmente passamos a evitar ter de contratar até o último instante (e mesmo depois de passado o último instante). Isso nos levou a firmar o propósito de desenvolver um sistema de recrutamento que se adequasse à nossa empresa e passamos a buscar algumas inspirações. Uma dessas inspirações foi o TrueAbility. Que sisteminha interessante! Você testa na prática os conhecimentos dos candidatos e extrai um resumo do rankeamento deles. Que vontade de simplesmente utilizar esse sistema. Seu único problema: não está traduzido para o português. A julgar pela amostra das últimas seleções, embora a maioria dos candidatos entenda razoavelmente o inglês (com alguns poucos fluentes no idioma), não queríamos que a habilidade de entender inglês prejudicasse algum candidato em potencial, o que relegou o TrueAbility a um segundo plano.

No entanto, a ideia de testar um candidato na prática passou a dominar a nossa visão de como desenhar o novo processo. Nós acabamos bolando uma máquina virtual recheada de problemas que costumamos enfrentar no dia a dia com nossos clientes – na verdade, todos os problemas da máquina virtual vieram de clientes e apenas foram adaptados para o nível da vaga e conter uma solução definitiva. Agora, onde encaixar esse teste prático?

Para encurtar o assunto, nosso processo acabou sendo formatado nas seguintes etapas:

  1. Anúncio (listas, jornal, LinkedIn etc);
  2. Coleta de currículos;
  3. Triagem geográfica (o candidato está onde precisamos dele? Se não está, pode/quer se mudar para o local de trabalho?);
  4. Triagem econômica (o candidato tem pretensão salarial compatível com a vaga ofertada? Se não tem, aceita as condições daquela vaga?);
  5. Análise de currículo (o candidato declara possuir os requisitos exigidos para a vaga? Esse é o momento para esclarecer alguma dúvida por email);
  6. Teste prático;
  7. Entrevista;
  8. Contratação.

Note que encaixamos o teste prático na máquina virtual antes da entrevista e, até a entrevista propriamente dita, todas as comunicações foram ou por telefone ou por email. Mesmo o teste prático é realizado remotamente.

Na última seleção testamos esse processo com um anúncio no LinkedIn. No período de coleta dos currículos, 94 foram enviados. Apenas 13 sobreviveram para chegar ao teste prático (o que já seria uma grande melhoria em relação à seleção anterior: melhor entrevistar 13 de 94 do que 30 de 100!). O teste prático cortou esse número em outros 50%. Somente 6 chegaram nele, o que é a demonstração do que havíamos detectado empiricamente no passado: a análise do currículo deixa muita margem a dúvidas.

Como maneira de avaliar nosso novo processo, acabamos entrevistando os 13 candidatos, mesmo os que foram cortados pelo teste prático. Embora presumindo algum viés – afinal, o entrevistador já conhecia o resultado do teste prático no momento da entrevista – essa ação acabou demonstrando que realmente o teste prático ajuda muito e, em um próximo processo seletivo, devemos entrevistar apenas os que forem bem rankeados no teste prático.

No final das entrevistas, havíamos localizado nosso futuro funcionário! E não foi o que melhor se saiu no teste prático. Ou seja, a entrevista é importante, como pudemos demonstrar. É como diz o Joel Spolsky (outra grande inspiração): “when you find the smart, gets-things-done candidate, you’ll know it”.

(Originalmente publicado no LinkedIn).

Oportunidades de Aplicação de Big Data em Saúde

Posted by – 22/03/2016

O campo da saúde é uma área heterogênea que envolve muitos atores com interesses ora sintônicos ora antagônicos e oferece muitas oportunidades para aplicação das disciplinas do Big Data.

Em primeiro lugar, quais são os atores e como podemos agrupá-los para estudar que oportunidades existem e podem ser oferecidas? A seguir um esboço que não pretende ser completo. Nos demais artigos dessa série explorarei cada um deles.

  • Provedores: são os que entregam diretamente os serviços de saúde, como hospitais e clínicas. Esse grupo está mais interessado no gerenciamento da saúde e da entrega de seus serviços e são mais parecidos com entidades de administração, preocupados com a gestão dos custos e a manutenção da qualidade. Duas subpopulações são facilmente identificáveis:

    • Administração: são os que gerenciam as contas, compras, relacionamento com pagadores, etc

    • Gerenciamento Assistencial: são os que cuidam para que os clientes tenham suas necessidades atendidas e estão interessados no fluxo de atendimento e na otimização dos processos intra e interdepartamentais

  • Força de trabalho: são os que trabalham na “última milha”, responsáveis pela prestação do serviço, tais como médicos, laboratoristas, técnicos de enfermagem ou de radiologia, etc

  • Pesquisadores: são os que consomem dados coletados pela força de trabalho para gerar estudos científicos e econômicos.

  • Pagadores: são os que pagam pelos serviços de saúde, em última análise, no Brasil, convênios e seguros saúde ou as diversas esferas governamentais. Uma parcela menor de pagadores são os próprios pacientes e são um caso particular do próximo grupo.

  • Clientes: são os que recebem os serviços de saúde, os pacientes. Como escrito acima, alguns desse grupo também são pagadores, mas a regra geral é que são clientes não diretamente pagantes (possuidores de seguro-saúde ou pacientes do SUS).

Tendo esses atores em vista, quais são as oportunidades de aplicação das disciplinas de Big Data para cada um deles ou conjunto deles? Vamos analisar isso em detalhes nos próximos posts.

(Originalmente publicado no site da Propus).

O Movimento Software Livre Morreu. Longa Vida ao Movimento Software Livre!

Posted by – 09/06/2014

Assistindo ao debate “Morreu o Movimento Software Livre no Brasil?”, do FISL15, resolvi compilar diversos pontos que foram marginalmente abordados no debate e que flutuam na minha cabeça há algum tempo, merecendo um aprofundamento nesse contexto.

Movimento Software Livre e Ideologias Alienígenas

O Movimento Software Livre é uma expressão, no âmbito técnico, do anseio natural de liberdade do ser humano. Foi o precursor de diversos movimentos de cultura livre que, de certa forma são mais antigos ainda que o próprio Software Livre, mas que até então não possuiam ferramentas coerentes para se desenvolver. No entanto, como todo movimento, é habitado por pessoas que têm aspirações diferentes e muitas vezes essas pessoas confundem suas próprias e particulares aspirações com as do movimento, levando a uma “identificação ideológica cruzada”, que acaba associando ao movimento Software Livre diversas outras ideologias de maneira até equivocada.

Embora o próprio Stallman não seja um comunista (expresso por suas ações ao longo da vida, mas literalmente também escrito por ele mesmo), o Movimento Software Livre acabou, em diversos lugares – inclusive o Brasil – sendo capturado pelo espectro da esquerda política. E isso só fez mal ao Software Livre. (Seria igualmente ruim se fosse capturado pela direita política, veja bem.) Isso fica amplamente evidente quando fazemos o contraponto entre Open Source e Free Software e identificamos isso como um embate entre capitalismo e comunismo, como foi feito no debate em questão. Nenhuma discussão poderia ser menos produtiva e mais equivocada do que essa! Especialmente porque não existe nenhuma incompatibilidade entre as 4 liberdades que definem um Software Livre e os 10 pontos da definição de Software de Código Aberto.

Exatamente. Para que fique bastante claro vou colocar em um parágrafo separado: não existe nenhuma incompatibilidade entre as 4 liberdades que definem um Software Livre e os 10 pontos da definição de Software de Código Aberto. Portanto, não há um conflito conceitual entre Software Livre e Software de Código Aberto, muito menos um conflito semelhante ao embate capitalismo versus comunismo.

More

Zotero and note-taking

Posted by – 24/06/2012

I was looking for an excuse to try Zotero and the perfect opportunity appeared when I got a whole lot of references to group for a month of Magnetic Ressonance studies I am currently taking. I was also pleased to notice it is packaged to Debian.

I am used to note-taking software. Back when I used a Palm m130 (and a Treo 650), I managed a lot of Memos I eventually migrated to Note-Everything in my current Android phone. Zotero, unfortunatelly, is not interfaceable with my phone (or I was still unable to figure out how to do so), but it’s powerful in managing references… beyond simple note-taking.

Is anyone using Zotero in a more ambitious way? I’ve read about people using it to keep large researchs to support fiction and non-fiction book-writing… I also watched some YouTube videos on it. As far as I went with it, Zotero might become an important piece in my toolbox wrt reference keeping, so I was just trying to figure out how many other niches it can fill…

As old as good: One Time Passwords

Posted by – 12/09/2008

People frequently ask me what I am doing typing on my Palm right before logging in one of my remote systems. The answer is quite simple: “generating my next password”. People always seem puzzled by that answer… Maybe I am just too old to have had only telnet sessions available to remote connections (that was the time before SSH took over)… or maybe I am just too paranoid regarding the access to my systems… Anyway, I like One Time Passwords, and here is an article I can refer to when I get asked again 😉

One Time Passwords are just that: passwords that are good for one time use. They never repeat and once used you can throw it away securely. They were quite common when the authentication was done in clear text (so that any man-in-the-middle could steal your passwords), back in the r-tools age (rcp, rsh, rlogin, rexec, etc). After the SSH-related tools took over, providing easy tunneling and remote access, MITM attacks were of much concern, so OTPs became less relevant. What a shame, for they even have a couple of standards for those!

But there’s still room for OTPs… Question: Is it easier to deploy a MITM attack or a keylogger? That’s right… We are always connecting to our remote systems in public terminals (well… at least I am – right now typing from the hospital computer), and a keylogger is so easily installed in one of those terminals, even remotely, that no one would ever get close to deploy a refined MITM attack just to steal someone’s password. One would just install a keylogger! All the security SSH provides would just be gone by then. That’s why I use SSH to connect to my remote machines, but use OTPs to authenticate myself.

It’s so easy to deploy it. In Debian you’ll find packages opie-server and libpam-opie and those are the only things you’ll need on the server side (besides SSH, obviously). OPIE means “One-time Passwords In Everything”, and combined with PAM, one can really use it everywhere.

After installing it, you’ll have to generate the password file for your account:

spectra@home:~$ opiepasswd -c
Adding spectra:
Only use this method from the console; NEVER from remote. If you are using
telnet, xterm, or a dial-in, type ^C now or exit with no password.
Then run opiepasswd without the -c parameter.
Using MD5 to compute responses.
Enter new secret pass phrase:
Again new secret pass phrase:
 
ID spectra OTP key is 499 ho6484
HAVE COOK LOLA AIRY NEIL ROAM

The pass phrase will be used to generate the passwords in a step before your login. Please, try not to forget it (specially if you’re following this article and playing with some remote system at the same time). Now you can edit /etc/pam.d/ssh file (or its equivalent in non-Debian systems) to require that kind of authentication. Mine just looks like this:

# /etc/pam.d/ssh
auth       required     pam_env.so
auth       required     pam_env.so envfile=/etc/default/locale
auth       required     pam_opie.so

First two lines are unrelated and just load the environment variables. Last line is where the fun is. Please, note two things: (1) I removed references to pam_unix.so, which is what would ask for my “real” password, that I want to disable (no login is allowed with that password). And (2), I declared it as required, meaning that failing it will keep one out of the system.

We are not ready yet! SSH will work by now, but will not present you the OTP challenge. Probably you could still login, but you’d have to remember which is the current password (Trust me, you would not!). To get the challenge you’ll need to enable it – in /etc/ssh/sshd_config change the following line:

ChallengeResponseAuthentication yes

That’s it. Now to login to your remote machine, that’s what will usually happen:

spectra@hospital:~$ ssh home
otp-md5 498 ho6484 ext, Response:
spectra@home:~$

Voilà! It asks for password #498. By default, it starts with 500 passwords and goes down from that. Password #498 were asked, so the next will be #497. After that, #498 is not useable anymore, and #496 is not useable yet. You can generate a list of those passwords (let’s say 10), print it and keep it in your pocket. This is the command you’d use for that:

spectra@home:~$ opiekey -n 10 498 ho6484
Using the MD5 algorithm to compute response.
Reminder: Don't use opiekey from telnet or dial-in sessions.
Sorry, but you don't seem to be on the console or a secure terminal.
Warning: Continuing could disclose your secret pass phrase to an attacker!
Enter secret pass phrase:
489: CALM INTO WEEK APS LOON VIE
490: HASH GYM RAID GOSH HOYT DUAL
491: BELL GIN RIFT HELM GUY BUNK
492: HEBE OBOE SUP LEG LULU LANG
493: HOYT JOT ASK JOG GIBE BETH
494: NASH MOOT HIND YEAH  YAP CARL
495: MATE OF BARD LAVA LEAK AHOY
496: TAB BAG KEY GILT AVID VEAL
497: MOLE FORM NIB LEER ROSS HAVE
498: SING WERE OVEN SOD VEIN NIBS

That is not so secure, since you can loose the paper and be doomed… Luckily there are lots of small softwares that does this generation for you. Some you can use from your Palm or from some J2ME-enabled phone (such as N95). Some your can use from another (trusted) computer. Some are even online, written in javascript!

There are at least one other side-benefit of using OPIE as above: You can give away your user password (even root password – OK, probably not a Good ThingTM), that the system would still be secure, since it only allows SSH authentications via OPIE! If the session is started with a username whose opiepasswd was not activated (first step… scroll back to the beginning of the article), SSH will greet you with a bogus challenge… only “opie-activated users” will be allowed to login with the above configuration.

Easy enough, isn’t it? Now, next time you see me typing on my Palm before opening an SSH connection you’ll know what I am doing… 😉

Oficina no Consegi 2008

Posted by – 30/08/2008

Ontem estive em Brasília para uma oficina de streaming de vídeo no Consegi 2008. A oficina foi excelente, com boa participação apesar de termos uma sala pequena e computadores não preparados.

A oficina foi ministrada como uma palestra, com introdução de Karinna Bueno, apresentação básica sobre Streaming a cargo do VJ Pixel, e estudo de dois casos, o da TVSL, a meu cargo e o da transmissão de um evento da ONU (utilizando software não-livre em parte), a cargo do Fabrício Tamusiunas do NIC.br.

Depois de um breve intervalo, comecei com alguns demos (uma vez que os computadores não haviam sido preparados, deixei de lado o hands-on) utilizando a versão 0.5.2 do Flumotion. (Essa é uma versão de desenvolvimento, o que trouxe alguns problemas, mas nada que não fosse superado facilmente… Agora tenho de tentar reproduzir o que ocorreu para ver se encontro o problema… mas isso é outra história…) Infelizmente o tempo agiu contra nós e não pude chegar nos demos mais interessantes, que são aqueles em que envolvo programação em Ruby com pipelines GStreamer… Vou ver se gravo um video desse demo para postar aqui.

Enquanto isso, a parte mais “formal” com a apresentação do caso da TVSL, pode ser encontrada aqui. Não há grandes diferenças em relação à palestra do Debian Day, uma vez que o caso é o mesmo… mas vale a pena dar uma olhadinha.

A todos que nos agüentaram quase a tarde inteira lá no Consegi, muito obrigado. Se tiverem dúvidas, perguntas, podem postar aqui mesmo.

Roteiro do Cibercrime

Posted by – 20/08/2008

Gostei da brincadeira do Alexandre Oliva e resolvi criar o meu próprio roteiro de uma situação de violação do Projeto de Lei Azeredo, só que dessa vez falando a respeito do artigo que considero mais problemático no famigerado projeto, o 285-B:

Obter ou transferir, sem autorização ou em desconformidade com autorização do legítimo titular da rede de computadores, dispositivo de comunicação ou sistema informatizado, protegidos por expressa restrição de acesso, dado ou informação neles disponível

A estorinha é entre Alice e Bob, ambos repórteres de um grande jornal da capital:

Alice: Olha só o que achei no site do Senador Edward Comstock… (aponta para Bob a tela de seu laptop). isto é um escândalo! Primeira página a caminho…

Bob: Cuidado… você leu as restrições de acesso?

A: Mas que restrições de acesso? Está público, na Internet.

B: Sim, mas você não pode sair por aí copiando coisas públicas dos sites dos outros sem ler as restrições de acesso…

A: Que bobagem… e onde estão as tais “restrições”?

B: Olha lá… no rodapé da página…

A: Hm… “Restrição de Acesso: O conteúdo desse site pode ser livremente citado desde que em um contexto favorável ao autor. Citá-lo de outra forma constitui violação desta restrição conforme o artigo 285-B da Lei nº 1.847.033/2008 (Lei do Cibercrime).”. Que que isso quer dizer?

B: Que você só pode publicar esse escândalo se esse contexto for favorável ao autor… Adeus primeira página.

A: Eu vou citar de qualquer forma. Não seria uma boa repórter se deixasse passar uma primeira página dessas!

B: Olha….

(Transição com uma tela escura escrito “Algum tempo depois…” e uma música de suspense.)

(Doze policiais entram na redação do jornal com escopetas em punho e cercam a mesa de Alice.)

Policial: Tenho um mandado de prisão temporária para a Srta. Alice Bliss Foote, por crime baseado na Lei nº 1.847.033/2008. Onde ela está?

Bob: Não sei, não veio trabalhar hoje, e não avisou a ninguém.

Policial: Revistem a redação. Os informantes disseram que ela está aqui em algum lugar.

(Bob cochichando para outro dos colegas da redação): Ela fugiu hoje… Disseram que viriam buscá-la… Deve estar a meio caminho do Uruguai a essa altura…

(colega de redação cochichando para Bob): Graças a Deus.

(Câmera vai se distanciando, vozes desencontradas na redação continuam a falar e os policiais continuam revirando tudo).

(Fade Out com um letreiro: “O Grande Irmão está observando”).

Palestra no Debian Day

Posted by – 16/08/2008

Hoje, aniversário do Debian, estamos de novo fazendo o Debian Day para comemorá-lo. Em Porto Alegre ele está acontecendo no Serpro. Em alguns minutos estarei fazendo uma palestra sobre Streaming com Theora, que será transmitida ao vivo pela TV Software Livre.

Devo acrescentar o arquivo da palestra aqui logo depois de ministrá-la, e deixarei aberto os comentários caso alguma dúvida não seja resolvida no ato.

Update 2008-08-17 00:50:00: Estou anexando o arquivo da palestra. Quanto à pipeline que estávamos tentando fazer funcionar… esqueci de colocar os queues eis ela pronta:

bash$ gst-launch-0.10 videotestsrc ! queue ! tee name=t ! fakesink t. ! queue ! ximagesink

Update 2008-08-27 18:36:00: O pessoal publicou o torrent do video da palestra. Mais informações no site do Debian-RS.