Gsoc forex

2017 Anúncios por email.

Este é um arquivo de todos os emails enviados para os alunos.

27 de agosto de 2017: menos de 46 horas para enviar sua avaliação final do GSoC e trabalhar!

Nossos registros indicam que você ainda não concluiu sua avaliação final do GSoC.

Certifique-se de concluir sua Avaliação final, que inclui o fornecimento do link para seu produto de trabalho antes de terça-feira, 29 de agosto, às 16:00 UTC. Essa é uma parte obrigatória da sua participação no GSoC e está acessível em seu painel. Siga as Diretrizes para envio de produtos de trabalho para sua apresentação.

Lembre-se, completar esta Avaliação Final é mais envolvido que as duas avaliações anteriores - não espere até o último minuto para completar a avaliação. Todos os alunos devem completar sua Avaliação Final antes do prazo ou eles falharão no GSoC. O prazo não pode ser prorrogado por qualquer motivo. Você trabalhou duro durante todo o verão, por favor, não perca este prazo e receba uma falha automática.

Datas importantes.

29 de agosto 16:00 UTC: Prazo final para enviar seu código e sua avaliação do seu mentor. Não espere até o último minuto para enviar, certifique-se de se comunicar com seu mentor, pois eles provavelmente exigirão que você mescle seu código antes do prazo para que eles possam avaliar seu trabalho. 1 de setembro: Prazo para atualizar seu endereço de entrega no site do programa 6 de setembro: Projetos bem-sucedidos de estudantes anunciados 10 de setembro: Pagamentos finais enviados aos alunos que passarem na avaliação final Início de outubro: Pacotes (camisetas, etc.) enviados para os alunos com endereços de envio em países não restritos.

Contacte-nos em gsoc-support @ google com todas as perguntas.

21 de agosto de 2017: as avaliações finais devem ser realizadas antes de terça-feira, 29 de agosto, às 16:00 UTC.

O GSoC 2017 está quase no fim e as avaliações finais estão agora abertas!

Neste ponto, seu projeto deve estar quase completo. Agora você já deve ter lido as Diretrizes para envio de produtos de trabalho e discutido com seu mentor como você enviará seu trabalho para visualização antes de enviar sua avaliação final, incluindo o fornecimento do link para seu produto de trabalho no painel.

Não deixe de concluir sua Avaliação final antes de terça-feira, 29 de agosto, às 16:00 UTC. Você pode acessá-lo no seu painel. Esta é uma parte obrigatória da sua participação no GSoC e não pode ser alterada após o envio.

Lembre-se, completar esta Avaliação Final é mais envolvido que as duas avaliações anteriores - não espere até o último minuto para completar a avaliação. Todos os alunos devem completar sua Avaliação Final antes do prazo ou eles falharão no GSoC.

A partir de 29 de agosto às 16h01 UTC, os mentores estarão concluindo as avaliações finais dos alunos e tomando as decisões de aprovação / reprovação.

Recebendo o pagamento final.

Se você receber uma avaliação de aprovação na sua avaliação final, receberá seu estipêndio no dia 10 de setembro.

Próximos prazos importantes.

21-29 de agosto: esfregue seu código, escreva a documentação, envie suas avaliações de mentores e vincule seu trabalho ao seu painel. 29 de agosto 16:00 UTC: Prazo final para enviar seu código e sua avaliação do seu mentor. Não espere até o último minuto para enviar, certifique-se de se comunicar com seu mentor, pois eles provavelmente exigirão que você mescle seu código antes do prazo para que eles possam avaliar seu trabalho. 1 de setembro: Prazo para atualizar seu endereço de entrega no site do programa 6 de setembro: Projetos bem-sucedidos de estudantes anunciados 10 de setembro: Pagamentos finais enviados aos alunos que passarem na avaliação final Início de outubro: Pacotes (camisetas, etc.) enviados para os alunos com endereços de envio em países não restritos.

Contacte-nos em gsoc-support @ google com todas as perguntas.

17 de agosto de 2017: a submissão final do código e as avaliações começam na próxima semana.

Você chegou às últimas semanas do GSoC 2017! Você deve concluir a codificação em seu projeto e trabalhar com seu mentor para atender às exigências de envio antes do prazo final de 29 de agosto às 16:00 UTC.

Certifique-se de seguir estas três etapas finais (em ordem) antes de 29 de agosto às 16:00 UTC. Comece agora! Não espere até o último minuto. Isso levará algum tempo para concluir todas as 3 etapas.

Discuta com seu mentor como você enviará seu trabalho e enviará uma pré-visualização assim que possível.

Isso é importante porque, se o seu link estiver quebrado (sem apontar para o código correto, etc.), você terá tempo de corrigi-lo antes de enviar sua Avaliação Final. Você não deseja enviar um link incorreto e falhar no GSoC por causa disso.

Não perca o prazo, porque você não recebeu uma resposta do seu mentor depois de enviar uma prévia. Se você não receber uma resposta de seu mentor até 28 de agosto às 23:00 UTC, envie sua avaliação mesmo assim. Uma avaliação perdida significa uma falha automática.

Envie sua avaliação final antes de 29 de agosto às 16:00 UTC.

Do seu painel, você poderá acessar a Avaliação Final a partir de 21 de agosto às 16:00 UTC. Assim como a 1ª e a 2ª avaliações, essa é uma parte obrigatória da sua participação no GSoC. A primeira pergunta pede-lhe para enviar o URL que aponta para o seu Produto de Trabalho para o GSoC 2017. Este será mostrado ao seu mentor para usar na sua decisão final de avaliação e será exibido no site GSoC público de projetos bem sucedidos. Você pode visualizar as perguntas finais de avaliação aqui.

Próximos prazos importantes.

21-29 de agosto: Esfregue seu código, escreva a documentação, envie suas avaliações de mentor 29 de agosto 16:00 UTC: Prazo final para enviar seu código e sua avaliação do seu mentor. Não espere até o último minuto para enviar, certifique-se de se comunicar com seu mentor, pois eles provavelmente exigirão que você mescle seu código antes do prazo para que eles possam avaliar seu trabalho. 1 de setembro: Prazo para atualizar seu endereço de entrega no site do programa 6 de setembro: Projetos bem-sucedidos de estudantes anunciados 10 de setembro: Pagamentos finais enviados aos alunos que passarem na avaliação final Início de outubro: Pacotes (camisetas, etc.) enviados para os alunos com endereços de envio em países não restritos.

Contacte-nos em gsoc-support @ google com todas as perguntas.

30 de julho de 2017: informações importantes de agosto e diretrizes para envio de produtos de trabalho.

Parabéns pela aprovação da 2ª avaliação do GSoC 2017! Você está agora na fase final mais excitante do programa. Certifique-se de aproveitar ao máximo as últimas 4 semanas do programa.

Orientações para envio de produtos de trabalho.

Certifique-se de ler as Diretrizes de Envio do Produto de Trabalho para que você esteja preparado para a fase de Avaliação Final, começando em pouco mais de 3 semanas.

Não deixe de discutir com seu mentor as melhores opções para o seu projeto. Cada organização terá sua própria preferência sobre como eles querem que você mostre seu produto de trabalho. Estas próximas semanas são um momento muito importante para garantir que você esteja se comunicando regularmente com seus mentores.

Lembre-se de que as Avaliações Finais se abrem para os alunos no dia 21 de agosto às 16:00 UTC e o prazo para enviar sua Avaliação Final é 29 de agosto às 16:00 UTC. E a avaliação final não é apenas uma avaliação do seu mentor, você deve incluir uma URL para o trabalho que você produziu no GSoC - certifique-se de ler atentamente as Diretrizes de Envio do Produto de Trabalho para os detalhes.

Próximos prazos importantes - ADICIONAR AOS SEUS CALENDÁRIOS!

1º de agosto: Pagamentos para a 2ª avaliação enviada à sua conta do Payoneer de 21 a 29 de agosto: esfregue seu código, escreva a documentação, envie as avaliações do seu mentor 29 de agosto 16:00 UTC: prazo para enviar seu código e sua avaliação do seu mentor. Não espere até o último minuto para enviar, certifique-se de se comunicar com seu mentor, pois eles provavelmente exigirão que você mescle seu código antes do prazo para que eles possam avaliar seu trabalho. As avaliações de mentores dos alunos começam em 29 de agosto. 1 de setembro: Prazo para atualizar seu endereço de entrega no site do programa (lembre-se, se você mora em um país restrito, pode enviar seu pacote para um amigo ou familiar em um país não restrito deve atualizar o perfil de remessa antes de 1º de setembro) 6 de setembro: Projetos bem-sucedidos de alunos anunciados 10 de setembro: Pagamentos finais enviados aos alunos que passarem na avaliação final Início de outubro: Pacotes (camisetas, etc.) enviados para os alunos aprovados no programa.

Contacte-nos em gsoc-support @ google com todas as perguntas.

24 de julho de 2017: segundas avaliações com vencimento antes de sexta-feira, 28 de julho às 16:00 UTC.

2 avaliações estão agora abertas!

Todos os alunos devem concluir uma segunda avaliação de seu mentor ou eles falharão no GSoC. Vá até o seu painel no site do programa GSoC e conclua sua avaliação do seu mentor antes de sexta-feira, 28 de julho, às 16:00 UTC.

Encorajamos você a fazer isso agora para não esquecer - deve levar menos de 3 minutos para ser concluído - é ainda mais curto que o último.

Se você não concluir a avaliação dentro do prazo, você falhará automaticamente no GSoC e não receberá nenhum estipêndio. O prazo não pode ser prorrogado por qualquer motivo. No mês passado, alguns alunos falharam porque não completaram o formulário de avaliação, por favor, não deixe que seja você.

Recebendo o segundo estipêndio.

Se você receber uma avaliação de aprovação, receberá seu estipêndio no dia 1º de agosto.

Orientações para envio de produtos de trabalho.

Na próxima semana, enviaremos os detalhes sobre as Diretrizes para envio de produtos de trabalho, que serão exigidas para todos os alunos em sua apresentação final no final de agosto.

Datas importantes.

24-28 de julho: Os estudantes submetem a segunda avaliação do Mentor 1 de agosto: O segundo pagamento de bolsa é enviado para todos os alunos que passarem na segunda avaliação. 21-29 de agosto: Estudantes submetem seu produto de trabalho (código) e uma avaliação final do seu Mentor. 5: Mentores avaliam Alunos em suas submissões finais de trabalho 1 de setembro: Data final para estudantes atualizarem seu endereço de entrega 6 de setembro: Alunos bem sucedidos são anunciados 10 de setembro: Alunos que passam recebem seu pagamento final Outubro: Pacotes com camisetas e adesivos enviado para estudantes que passam no programa.

Lembre-se de usar o e-mail gsoc-support @ google para dúvidas sobre os administradores de programa do Google.

17 de julho de 2017: sua segunda avaliação está chegando!

Segunda avaliação.

Lembre-se de que você precisará concluir sua segunda avaliação entre 24 e 28 de julho. Você pode visualizar as 2as questões de avaliação aqui.

Datas importantes.

24-28 de julho: Os estudantes submetem a segunda avaliação do Mentor 1 de agosto: O segundo pagamento de bolsa é enviado para todos os alunos que passarem na segunda avaliação. 21-29 de agosto: Estudantes submetem seu produto de trabalho (código) e uma avaliação final do seu Mentor. 5: Mentores avaliam Alunos em suas submissões finais de trabalho 1 de setembro: Data final para estudantes atualizarem seu endereço de entrega 6 de setembro: Alunos bem sucedidos são anunciados 10 de setembro: Alunos que passam recebem seu pagamento final Outubro: Pacotes com camisetas e adesivos enviado para estudantes que passam no programa.

Lembre-se de usar o e-mail gsoc-support @ google para dúvidas sobre os administradores de programa do Google.

29 de junho de 2017: GSG URGENTE 2017: o 1º prazo de avaliação é sexta-feira, 30 de junho às 16:00 UTC.

Você deve enviar sua primeira avaliação do GSoC antes de 30 de junho às 16:00 UTC ou você falhará no GSoC 2017.

Nossos registros indicam que você ainda não concluiu sua primeira avaliação do GSoC sobre seu mentor. Você deve concluir uma avaliação do seu mentor antes de 30 de junho às 16:00 UTC ou você falhará no GSoC. Vá até o seu painel no site do programa GSoC e conclua sua avaliação do seu mentor antes de 30 de junho às 16:00 UTC.

Encorajamos você a fazer isso agora, para que você não se esqueça. Isso levará menos de 10 minutos para ser concluído.

Se você não concluir a avaliação dentro do prazo, você falhará automaticamente no GSoC e não receberá nenhum pagamento. O prazo não pode ser prorrogado por qualquer motivo. Todos os anos, há alguns alunos que teriam passado se tivessem tempo para preencher o formulário de avaliação, por favor, não deixe que seja você.

26 de junho de 2017: as primeiras avaliações devem ser realizadas antes de sexta-feira, 30 de junho, às 16:00 UTC.

Primeiras Avaliações.

As avaliações estão agora abertas!

Se você acertar o bug de 99 anos ao enviar sua avaliação hoje cedo, ele foi corrigido. Por favor, tente novamente.

Todos os alunos devem concluir uma avaliação de seu mentor ou eles falharão no GSoC. Vá até o seu painel no site do programa GSoC e conclua sua avaliação do seu mentor antes de 30 de junho às 16:00 UTC.

Encorajamos você a fazer isso agora, para que você não esqueça - deve levar menos de 10 minutos para ser concluído.

Se você não concluir a avaliação dentro do prazo, você falhará automaticamente no GSoC e não receberá nenhum estipêndio. O prazo não pode ser prorrogado por qualquer motivo. Todos os anos, há alguns alunos que teriam passado se tivessem tempo para preencher o formulário de avaliação muito curto, por favor, não deixe que seja você.

Recebendo o primeiro salário.

Se você receber uma avaliação de aprovação, mas ainda não se registrou na sua conta do Payoneer usando o link que lhe enviamos em maio, você não receberá nenhum estipêndio na próxima semana. Você receberá seu estipêndio depois de se inscrever com o Payoneer e sua conta ser aprovada.

Datas importantes.

30 de junho 16:00 UTC: Primeiro Prazo de Avaliação: Os alunos enviam sua avaliação do seu Mentor (e Mentores submetem sua avaliação dos alunos) 5 de julho: O primeiro pagamento é enviado aos alunos que passam pela primeira avaliação (e que completaram o registro do Payoneer) 24 a 28 de julho: Segunda avaliação (para mentores e alunos)

Lembre-se de usar o e-mail gsoc-support @ google para dúvidas sobre os administradores de programa do Google.

Os dias 3 e 4 de julho são feriados nos Estados Unidos, por favor, seja paciente e a equipe entrará em contato com você na quarta-feira, 5 de julho.

6 de junho de 2017: Lembretes importantes para junho.

Esperamos que sua primeira semana de codificação tenha começado muito bem!

Lembretes! Até 15 de junho:

Registre-se para sua conta Payoneer usando o link que enviamos a você em 4 de maio Se você precisar enviar um formulário de impostos nos EUA (descrito detalhadamente no e-mail de 14 de maio), preencha o formulário usando o link direto enviado pela Payoneer. Se você deseja aproveitar a assinatura gratuita de 1 ano do LWN, deverá registrar-se em sua conta usando o link que lhe enviamos no dia 17 de maio. O link para registro expirará no dia 15 de junho.

Perguntas freqüentes de Payoneer.

Eu me registrei em uma conta Payoneer usando o link que você enviou, mas não sei se minha conta está bem. Como posso eu saber?

Faça login na sua conta do Payoneer e verifique se sua conta está ativa e vinculada ao programa Google Summer of Code, consultando a seção Fontes de financiamento no seu Painel. Entre em contato com Payoneer diretamente se tiver alguma dúvida sobre o status ou a precisão de sua conta.

Não poderei concluir o meu registo Payoneer até 15 de junho. O que isso significa para mim?

Seu pagamento (s) será atrasado. Não podemos colocar fundos em uma conta que não existe. O tempo de atraso dependerá de quanto tempo você leva para concluir seu registro e aprová-lo pelo Payoneer. A aprovação da Payoneer geralmente leva de 3 a 7 dias úteis se você enviar os documentos corretos.

Recebi um link de Payoneer instruindo-me a preencher um formulário de impostos nos EUA.

O que acontece se eu não tiver preenchido o formulário fiscal até 15 de junho?

Seu pagamento será atrasado. Não podemos pagá-lo até que você preencha o formulário de imposto obrigatório.

Não creio que seja necessário preencher um formulário fiscal dos EUA, o que eu faço?

Entre em contato com gsoc-support @ google e explique por que você não acha que precisa preencher o formulário.

Eu sou um cidadão dos EUA e estou freqüentando uma escola fora dos EUA e não recebi o link de formulário de imposto de Payoneer. O que eu faço?

Entre em contato com gsoc-support @ google e teremos certeza de que Payoneer envia um link para o formulário fiscal para você.

Quero alterar os detalhes da conta na minha conta do Payoneer, como faço isso?

Quaisquer alterações relacionadas à sua conta do Payoneer devem ser feitas diretamente no seu painel no Payoneer. Se necessário, entre em contato diretamente com o Payoneer usando o site dele ou ligando para ele. Se você estiver ligando de dentro dos Estados Unidos, disque 1-800-251-2521. Se você estiver ligando de fora dos Estados Unidos, disque 1-646-658-3695.

Avaliações

Interessado em saber mais sobre as questões que serão colocadas nas avaliações do GSoC? Você pode visualizar as perguntas aqui.

Próximas datas futuras.

15 de junho: Prazo final para se inscrever em uma conta Payoneer (e formulários de imposto *) 15 de junho: Prazo para se inscrever gratuitamente na assinatura de 1 ano do LWN 26 a 30 de junho: Avaliação 1: Os alunos enviam a primeira avaliação do Mentor (e os Mentores enviam o primeiro avaliação dos alunos) 5 de julho: O primeiro pagamento sai para aqueles que passaram pela primeira avaliação.

Lembre-se de usar o e-mail gsoc-support @ google para dúvidas dos administradores de programa do Google.

* Os formulários fiscais são necessários apenas para cerca de 10% de você.

14 de maio de 2017: Informações Importantes sobre a Semana 2 do Estudante.

Esperamos que sua primeira semana e meia como estudante do GSoC 2017 tenha sido divertida e emocionante. Até agora você deveria ter sido contatado pelo seu Mentor e está aprendendo mais sobre sua comunidade e a base de código, lendo a documentação e trabalhando no seu plano de projeto para o verão.

Atualizamos a página Payoneer / Student Payment Information com respostas às perguntas mais frequentes. Para estudantes na Índia, há um campo pedindo "Código de Propósito": Se você ainda não tiver concluído seu registro, use P1009 - Serviços de Arquitetura. Se você já se registrou e usou um código diferente, tudo bem, não há necessidade de alterá-lo. Muitos estudantes não sediados nos EUA nos perguntam se é melhor receber fundos em sua moeda local ou em dólares americanos. A nossa experiência é que a sua moeda local é preferível porque as taxas de câmbio do Payoneer são frequentemente melhores do que o que o seu banco local pode cobrar. O Google cobre a maioria das outras taxas em torno de seus cartões ou transferências bancárias, mas não cobre taxas de câmbio. Cada banco é diferente, o que dificulta que o Google ou o Payoneer forneçam uma estimativa específica de qual método é melhor. Depois de enviar o seu registro Payoneer, normalmente levará de 1 a 4 dias úteis para receber um e-mail de aprovação do Payoneer dizendo "Parabéns - o seu pedido de conta do Payoneer foi aprovado!" Se você estiver sujeito a impostos nos EUA, poderá receber uma solicitação para preencher formulários de impostos após a aprovação. Veja abaixo para mais informações.

Se você tiver dúvidas sobre sua conta Payoneer, você deve entrar em contato com o Payoneer diretamente usando o site dele ou ligando para ele. Se você estiver ligando de dentro dos Estados Unidos, disque 1-800-251-2521. Se você estiver ligando de fora dos Estados Unidos, disque 1-646-658-3695.

Payoneer responderá às suas perguntas dentro de alguns dias úteis (normalmente mais cedo). Por favor, seja paciente.

Cartas CPT.

Se você precisar de uma carta CPT, por favor, esteja ciente de que não podemos alterar as datas para nada além das datas oficiais de codificação: 30 de maio a 21 de agosto.

O primeiro grupo de cartas CPT que enviamos incluiu o período de vinculação da comunidade e o período final de avaliação: 4 de maio a 29 de agosto. Se você precisar atualizar seu formulário para refletir as datas de 30 de maio a 21 de agosto, envie uma nova solicitação. a carta original não é aceita pela sua escola).

Não nos peça para mudar a data final no início de agosto. Cabe a você determinar se sua escola aceitará as datas de codificação com as quais você concordou no registro. Se você não puder trabalhar devido às especificações do seu visto F1 ou J1 durante essas datas, precisará discutir com sua escola o que isso significa para você (as opções podem incluir: não aceitar nenhum pagamento, retirar-se do programa, etc. ).

Não solicite uma carta CPT apenas para obter a prova de que você foi aceito no programa. Enviaremos uma carta dizendo que você foi aceito no programa na próxima semana.

Se você é um cidadão dos EUA, detentor de cartão verde dos EUA, residente nos EUA, com visto ou fisicamente presente nos EUA durante o período de codificação do GSoC, deve enviar um formulário de imposto dos Estados Unidos para receber seu estipêndio.

Para todos os estudantes ou residentes fora dos EUA, se você não atender a nenhum dos critérios listados acima, não precisará preencher um formulário de impostos nos EUA no Payoneer.

As solicitações de formulários de impostos serão enviadas automaticamente para os alunos que freqüentam universidades dos Estados Unidos e aqueles com endereço residencial nos EUA. Esses formulários fiscais serão enviados por e-mail para você pelo Payoneer no prazo de 10 dias após a aprovação da sua conta pelo Payoneer.

Se a sua universidade não estiver nos EUA e seu endereço residencial não estiver nos EUA, mas você acredita que ainda precisa preencher um formulário de imposto nos EUA, envie um e-mail para gsoc-support @ google e uma solicitação de formulário fiscal será enviada para você.

Você deve preencher o formulário de imposto pelo site do Payoneer antes de 15 de junho de 2017 para receber seu primeiro pagamento no prazo.

É sua responsabilidade consultar um profissional de impostos se tiver dúvidas sobre como qualquer dinheiro recebido do Google Summer of Code afetará você.

Lista de discussão de estudantes do GSoC.

Adicionamos todos que optaram pela Lista de Alunos do GSoC. Por favor, lembre-se que esta lista é apenas para alunos do passado e do presente. Existem mais de 6700 pessoas na lista, portanto, use-as para perguntas que você acha que podem ser úteis para todos os alunos - não perguntas específicas para você (atualizando seu endereço de entrega, sua conta do Payoneer, etc.)

Arquivo de Email.

Próximas datas futuras.

Agora - 29 de maio: Período de adesão da comunidade 30 de maio: A codificação começa oficialmente em 15 de junho: Prazo para se inscrever em uma conta Payoneer e enviar seu formulário 26 a 30 de junho: os alunos submetem a primeira avaliação do seu mentor.

Lembre-se de usar o e-mail gsoc-support @ google para dúvidas dos administradores do Google.

4 de maio de 2017: Informações sobre o subsídio do GSoC 2017.

Parabéns novamente por ter seu projeto aceito para participar do Google Summer of Code 2017!

Se você ainda não leu as Informações para alunos aceitos, você deve fazer isso agora.

Este e-mail contém informações personalizadas relacionadas ao seu salário. Você DEVE seguir os passos abaixo ou você não será pago.

Seu estipêndio total, se você concluir com êxito o Google Summer of Code 2017, será de X USD com base em sua universidade localizada em X.

Ao passar com sucesso em cada etapa do programa, você receberá seu salário com base nessa programação:

X USD após 3 de julho (Primeira Avaliação) X USD após 1º de agosto (Segunda Avaliação) X USD após 7 de setembro (Avaliação Final)

Para mais informações sobre o seu salário, por favor visite a página de Bolsas Estudantis.

Para receber qualquer estipêndio do GSoC, você deve se inscrever em uma conta do Payoneer antes de 15 de junho de 2017.

IMPORTANTE: você deve usar o link abaixo para se inscrever em sua conta do GSoC Payoneer para garantir que esteja adequadamente associado ao seu cadastro no GSoC. Não vá diretamente ao site Payoneer e registre-se. Se você não usar este link, você não será pago.

Se você já tem uma conta Payoneer, você ainda deve usar o link acima. Você será perguntado se você já tem uma conta Payoneer. Clique em "sim" e você será orientado sobre como conectá-lo ao GSoC 2017.

Para obter ajuda com o registro Payoneer, visite o site ou ligue para eles. Se você estiver ligando de dentro dos Estados Unidos, disque 1-800-251-2521. Se você estiver ligando de fora dos Estados Unidos, disque 1-646-658-3695.

Para quaisquer outras questões, por favor envie um email para gsoc-support @ google.

Salvo indicação em contrário, o conteúdo desta página está licenciado sob a licença Creative Commons Attribution 3.0. Para detalhes, consulte nossas Políticas do Site. Java é uma marca registrada da Oracle e / ou de suas afiliadas.

Idéias do Projeto 2018 do Google Summer of Code (GSoC).

A Namecoin, infelizmente, não foi aceita como uma organização mentora para o Google Summer of Code 2018. No entanto, ainda estamos felizes em orientar projetos (contanto que você não seja pago pelo Google). Entre em contato se ainda estiver interessado. A página de ideias do GSoC 2018 original é a seguinte.

Se você estiver interessado em trabalhar em um dos seguintes projetos, entre em contato conosco! Para discussões de baixa latência, muitos de nossos desenvolvedores podem ser contatados através do # namecoin-dev (também estamos presentes no #namecoin). Se você não conseguir uma resposta sobre isso (o que é possível, pois vários de nossos desenvolvedores não poderão responder durante a aula ou o trabalho), poste no fórum. Se você tem as suas próprias ideias para bons projetos Namecoin, gostaríamos de ouvi-los e apoiá-los também! Todas as idéias do projeto são bastante personalizáveis ​​com base em seus interesses e habilidades (é por isso que os campos de "Dificuldade" não são completamente precisos). Por favor, fale conosco no início da formação de sua proposta; isso nos permite dar um feedback mais útil.

Cliente leve.

O Namecoin precisa de um cliente leve, que possa ser usado para registrar / gerenciar nomes ou obter valores de nome sem confiança, mas sem a necessidade de armazenar o blockchain completo. Existem várias ideias possíveis para lidar com isso, dependendo de seus interesses e gostos. Alguns exemplos de como isso pode ser feito:

Portar um cliente Bitcoin leve existente para Namecoin. Nós preferimos projetos que visam apoiar os recursos de nomeação do Namecoin, não apenas os recursos de moeda. Você pode achar útil esta lista de carteiras de Bitcoin, mas esteja ciente de que nem todas as carteiras de Bitcoin listadas aqui são adequadas. Em particular, os clientes que não são totalmente open-source não se qualificam; nem clientes que requerem um componente de servidor que não seja totalmente de código aberto; nem carteiras que exijam um sistema operacional que imponha DRM, como o Apple iOS; nem as carteiras que exigem confiança total de terceiros. Se você estiver portando um cliente que usa a biblioteca BitcoinJ, talvez ache útil a biblioteca libdohj de Ross Nicoll. Sistema de confirmação do banco de dados de nomes (por exemplo, um sistema de árvore Merkle). Isso pode tornar muito mais dispendioso para os serviços de pesquisa mentirem sobre o estado dos nomes, tornar essas mentiras mais facilmente detectáveis ​​e permitir que os clientes leves baixem apenas um subconjunto do banco de dados de nomes. Isso tem algumas semelhanças com os compromissos estabelecidos pelo UTXO que foram propostos no Bitcoin (e usados ​​no protocolo da Electrum), mas as necessidades do Namecoin não correspondem exatamente às do Bitcoin. Você pode achar interessante a proposta de Daniel Kraft.

Adicionar comandos de protocolo de fio P2P pode ser bom se ajudar você a realizar isso, desde que isso não faça com que nossa base de código divirja muito do Bitcoin upstream. Mudar as regras de consenso de blockchain não está fora da mesa, mas seria necessário convencer-nos de que isso tem um benefício claro. Você é livre para propor uma base de código de sua escolha para trabalhar, assim como suas próprias idéias para implementar um cliente leve e discutir sua escolha com a comunidade. Você pode achar interessante os seguintes escritos de Hugo Landau, embora os leve com um pouco de sal, já que estão um pouco desatualizados: Tipos de Implantação do Namecoin e Estado do Namecoin.

Requisitos: Se portar um cliente Bitcoin existente, um forte entendimento de como o Bitcoin e o Namecoin funcionam. Se estiver trabalhando em um sistema de comprometimento de banco de dados de nomes, esteja familiarizado com sistemas de comprometimento, como aqueles que usam árvores Merkle.

Resultados esperados / entregas: Um cliente leve que é utilizável e suporta transações de nome.

Mentores Possíveis: Jeremy (confirmado), Brandon (confirmado)

Integração de nome de domínio com plataformas / aplicativos adicionais.

O Namecoin atualmente suporta a integração com os resolvedores de DNS em sistemas operacionais de desktop, como GNU / Linux, Windows e macOS. A integração com a rede de anonimato Tor em sistemas operacionais de desktop (com nomes de domínio apontando para endereços IP, nomes DNS e serviços em cebola) também está funcionando. No entanto, existem vários outros aplicativos e ambientes onde os nomes de domínio do Namecoin seriam benéficos. Alguns destes são:

O sistema operacional Android móvel. Isso também pode incluir a portabilidade de um Android Light Client para o Namecoin. A rede de anonimato do I2P (os nomes apontam para endereços IP, nomes DNS e e-sites). (Nota: os desenvolvedores do Kovri estão interessados ​​nisso.) A rede de hospedagem anônima da Freenet (os nomes apontam para freesites). A rede de hospedagem descentralizada ZeroNet (os nomes apontam para os sites da ZeroNet). O ZeroNet já tem suporte parcial para o Namecoin, mas atualmente usa um servidor centralizado para procurar nomes. A rede de hospedagem descentralizada do IPFS (os nomes apontam para sites do IPFS).

Você é livre para integrar os nomes de domínios do Namecoin em qualquer plataforma (s) adicional (is) ou aplicativo (s) de sua escolha, desde que eles não imponham o DRM (isso significa que o Apple iOS não é aceitável). Em muitos casos, é provável que você se beneficie de conversar com os desenvolvedores de qualquer aplicativo com o qual você estaria trabalhando (por exemplo, se estiver implementando o suporte do Namecoin no I2P, talvez você queira conversar com os desenvolvedores de uma implementação do cliente I2P) .

Requisitos: Familiaridade com qualquer plataforma (s) ou aplicativo (s) com o qual você estaria integrando o Namecoin.

Resultados esperados / Entregas: Uma integração funcional dos nomes de domínio do Namecoin com a (s) plataforma (s) ou aplicação (ões) de sua escolha.

Mentores Possíveis: Jeremy (confirmado), anonimal (se integrando Namecoin com Kovri; confirmado)

Integração TLS com Plataformas Adicionais / Aplicativos.

O Namecoin atualmente suporta a integração com implementações TLS (como uma alternativa descentralizada para autoridades de certificação) em um pequeno número de plataformas e aplicativos: substituições positivas (certificados auto-assinados são permitidos se corresponderem ao blockchain do Namecoin) para Windows e (no GNU / Linux) NSS e substituições negativas (os certificados emitidos por CA não são permitidos se não corresponderem ao blockchain do Namecoin) para o Chromium. No entanto, nosso suporte existente é bastante hacky e tem algumas desvantagens, e gostaríamos de oferecer suporte a mais plataformas. Alguns exemplos de coisas que gostaríamos de ver suportam o Namecoin para TLS:

Também pode ser interessante simular a HSTS redirecionando automaticamente HTTP para HTTPS para nomes de domínio Namecoin que tenham um certificado TLS listado na blockchain. Isso evitaria ataques no estilo da SSL mesmo que um cabeçalho da HSTS ainda não tenha sido recebido.

Requisitos: familiaridade com os certificados TLS e como eles são manipulados por qualquer plataforma / aplicativos com os quais você opte por trabalhar.

Resultados esperados / Entregas: Uma integração funcional do Namecoin para verificação de certificado com a (s) plataforma (s) ou aplicação (ões) de sua escolha.

Mentores Possíveis: Jeremy (confirmado)

Integração de identidade com aplicativos adicionais.

O Namecoin pode ser usado para identidades com uma variedade de protocolos e aplicativos. Alguns destes são:

Login único do site. O NameID de Daniel Kraft é uma interessante prova de conceito disso, mas é questionável se o OpenID ou uma extensão do Firefox são as melhores maneiras de fazer isso. Por exemplo, o TLS CCA (autenticação de certificado de cliente) e o FIDO foram sugeridos como alternativas mais padronizadas. Login do cliente OpenSSH. Bitmessage Daniel Kraft implementou uma prova de conceito que agora faz parte do Bitmessage, mas pode ser significativamente melhorada, por ex. implementando pesquisas reversas (endereços Bitmessage para as identidades do Namecoin). Tenha cuidado com o bloat do blockchain; pode ser mais escalável implementar implementações reversas no protocolo Bitmessage em vez do blockchain do Namecoin. OTR (Off The Record Messaging) e OMEMO. Daniel Kraft implementou uma prova de conceito para o Pidgin, mas seu código é obsoleto e o próprio Pidgin não é mais considerado particularmente seguro. Existem muitos clientes de mensagens instantâneas que suportam OTR ou OMEMO; Adicionar suporte a Namecoin a um deles seria benéfico. OpenPGP. Phelix implemented a proof-of-concept of a Namecoin OpenPGP keyserver, but it is based on outdated code and might benefit from a fresh attempt. Cryptocurrency addresses. May be relevant to the work by Netki and by Monero’s OpenAlias project.

Requirements : Familiarity with whatever protocol(s) or application(s) you would be integrating Namecoin with.

Expected Outcomes/Deliverables : A working integration of Namecoin identities with the protocol(s) or application(s) of your choice.

Possible Mentors : Jeremy (confirmed)

Name Trading UI.

Namecoin’s protocol supports atomic name trades, in which Alice can purchase a name from Bob without counterparty risk. This could help reduce issues with squatted names. You could make this functionality available in the UI in a simple way, and possibly investigate a method for buyers and sellers to find each other (e. g. a decentralized bulletin board). Both interactive trades (where both parties select and confirm each other) and non-interactive trades (where a trade offer can be posted publicly and another user can accept the offer without further interaction) are possible; you can implement either (or both). You may find Phelix’s ANTPY and Ryan Castellucci’s nametrade implementations to be interesting.

You are free to implement a name trading UI in any Namecoin wallet that you choose. (Since Namecoin Core is the only currently available wallet application, this would mean either implementing your name trading UI into Namecoin Core or combining some name trading UI tasks with creating a Lightweight Client.)

Requirements : Familiarity with UI design in whatever language and UI framework your chosen wallet application uses. (For example, Namecoin Core uses C++ with Qt.)

Expected Outcomes/Deliverables : Modified Namecoin wallet software with your atomic name trading UI.

Possible Mentors : Brandon (confirmed), Jeremy (confirmed)

Namecoin suffers the same problems with traceability (lack of anonymity) of coin flows that Bitcoin does, plus additional linkability given the data attached to name transactions. When Namecoin is used for its stated purpose to provide censorship-resistant, MITM-resistant browsing and registration of domains for possibly controversial purposes (e. g. under repressive regimes), this may be even a bigger problem than with Bitcoin. You could improve this situation in several ways:

Improve usability of registering a name anonymously by automating a purchase of namecoins using an anonymous currency like Monero or Zcash as part of the name registration process. This reduces the risk of private data leaking while purchasing namecoins (e. g. banking details at an exchange, or Bitcoin blockchain analysis data). Integrating with a decentralized exchange such as Bisq might be a useful way to do this (this might also make it easier to register Namecoin names with national currencies). Future advances in blockchain technology such as atomic cross-chain trades might be applicable, so try to make sure that your code could be reused with as few changes as possible for such use cases once they’re ready. Keep each registered name separate on the blockchain. This reduces the risk of private data leaking in the Namecoin blockchain. This might be done using the Coin Control or HD Wallet features of wallet software. Improve the ability for Namecoin-related software to run safely when routed over Tor or other anonymity networks. This might include testing for and fixing proxy leaks, application-layer protocol leaks, timing metadata leaks, and incorrect or missing stream isolation, among other things. It’s okay if this work includes some fixes to upstream software (e. g. Bitcoin wallet software), but a significant component of your project should be Namecoin-specific.

You are free to choose any anonymity improvements you wish in any Namecoin-related software of your choice.

Requirements : Familiarity with Bitcoin’s anonymity properties/attacks.

Expected Outcomes/Deliverables : Modified Namecoin software with your anonymity improvements.

Possible Mentors : Jeremy (confirmed)

Scalability: Segregated Name Values.

The data attached to names in Namecoin is permanently part of the blockchain, which is bad for scalability. Jeremy Rand wrote a rough proposal called Segregated Name Values (SegVal), which would allow name data to be discarded from the network after it has expired, thereby significantly improving scalability. You could implement SegVal and deploy it on a Namecoin testnet, for merging later to the production Namecoin mainnet.

Requirements : Familiarity with C++ and the Bitcoin Core codebase.

Expected Outcomes/Deliverables : SegVal deployed on a Namecoin testnet.

Possible Mentors : Jeremy (confirmed)

Block Explorer.

Namecoin would benefit from a high-quality libre block explorer with support for name transactions. Brandon Roberts has already ported Bitcore to Namecoin, which might make it feasible to port the Insight block explorer to Namecoin.

Requirements : Basic familiarity with a Bitcoin block explorer implementation.

Expected Outcomes/Deliverables : A Namecoin block explorer with support for name transactions.

Possible Mentors : Brandon (confirmed), Jeremy (confirmed)

Packaging Improvements.

Namecoin’s various subprojects would benefit from improvements in the packaging process. Por exemplo:

GNU/Linux packages for Namecoin Core, ncdns, lightweight clients, etc. Reproducible builds for ncdns, lightweight clients, etc. (Namecoin Core binaries are already reproducible, but we’d love to see reproducible GNU/Linux packages for Namecoin Core.)

Requirements : Familiarity with build systems, packaging, and/or reproducible builds.

Expected Outcomes/Deliverables : Modified Namecoin software build scripts with your improvements; possibly also deployed PPA/COPR-style packages or official distribution packages if you choose to do so.

Possible Mentors : Jeremy (confirmed)

Hardening/Sandboxing Improvements.

Various hardening and sandboxing technologies exist, e. g. AppArmor, Bubblewrap, Qubes’s AppVM’s, and Subgraph’s Oz. It would be interesting to utilize some of these with software from the Namecoin ecosystem.

Requirements : Familiarity with the hardening/sandboxing technology or technologies that you plan to use.

Expected Outcomes/Deliverables : Modifications to the Namecoin-related software of your choice to use the hardening/sandboxing technology or technologies of your choice.

Possible Mentors : Jeremy (confirmed)

Your Own Namecoin Use or Enhancement.

Namecoin can be used for lots of novel and interesting use cases, and existing use cases are open for improvement. Propose your own use case or improvement, and discuss it with us! Anecdotally, we’ve heard from other GSoC mentor organizations that the most successful projects were ones that a student came up with themselves rather than took from a suggestion list, so don’t be afraid to be creative. Also note that there’s nothing wrong with working on more than one of the categories we’ve suggested. For example, anonymous users often have bandwidth constraints, so combining Anonymity with a Lightweight Client might make sense; just be careful not to choose a bigger scope than you can expect to do over the summer.

vanitasvitae's blog.

Just another FSFE Fellowship Blogs site.

Fourth week of GSoC and OMEMO thoughts.

Evaluation phase is there! Time went by faster than I expected. That’s a good sign, I really enjoy working on Smack (besides when my code does not work ).

I spent this week to work on the next iteration of my Jingle code. IBB once again works, but SOCKS5 still misses a tiny bit, which I struggle to find. For some reason the sending thread hangs up and blocks just before sending begins. Its probably a minor issue, which can be fixed by changing one line of code, nevertheless I’m struggeling to find the solution.

Apart from that it turned out, that a bug with smack-omemo which I was earlier (unsuccessfully) trying to solve resurrected from the land of closed bug reports. Under very special conditions pubsub results seem to only arrive in Smack exactly after the result listener timed out. This keeps smack-omemo from fetching device bundles on some servers. I originally thought this was a configuration issue with my server, but it turned out that aTalk (a Jitsi for Android fork which is working on including OMEMO support) faces the exact same issue. Looks like I’ll have to investigate this issue once more.

OMEMO – Reflections.

It appears that soon the council will decide on the future of OMEMO. I really hope, that the decision will make everyone happy and that the XMPP community (and – perhaps more important – the users) will benefit from the outcome.

There are multiple options for the direction, which the development of OMEMO can take. While everybody aggrees, that something should happen, it is not clear what .

OMEMO is already rather well deployed in the wild, so it is obviously not a good idea to break compatibility with existing implementations. A few months ago, OMEMO underwent a very minor protocol change to mitigate a vulnerability and even though Conversations (birthplace to OMEMO) made a smooth transition over multiple versions, things broke and confused users. While things like this probably cannot be avoided in a protocol which is alive and changing, it is desirable to avoid breaking stuff for users. Technology is made for users. Keeping them happy should be highest priority.

However, at the moment not every user can benefit from OMEMO since the current specification is based on libsignal, which is licensed under the GPLv3. This makes the integration in premissively licensed software either expensive (buying a license from OWS), or laborious (substitute libsignal with other double ratchet library). While the first option is probably unrealistic, the second option has been further investigated during discussions on the standards mailing list.

Already the “official” specification of OMEMO is based on the Olm library instead of libsignal. Olm more or less resembles OWSs double ratchet specification, which has been published by OWS roughly half a year ago. Both Olm and libsignal got audited, while libsignal got significantly more attention both in the media and among experts. One key difference between both libraries is, that libsignal uses the Extended Triple Diffie Hellman (X3DH) key exchange using the XEdDSA signature scheme. The later allows a signature key to be derived from an encryption key, which spares one key. In order to use this functionality, a special conversion algorithm is used. While apparently this algorithm is not too hard to implement, there is no permissive implementation available in any established, trusty crypto library.

In order to work around this issue, one proposal suggests to replace X3DH completely and switch to another form of key exchange. Personally I’m not sure, whether it is desirable to change a whole (audited) protocol in order to replace a single conversion algorithm. Given the huge echo of the Signal protocol in the media, it is only a matter of time until the conversion algorithm makes its way into approved libraries and frameworks. Software follows the principle of supply and demand and as we can conclude from the mailing list discussion, there is quite a lot of demand even alone in the world of XMPP.

I guess everybody aggrees that it is inconvenient, that the “official” OMEMO XEP does not represent, what is currently implemented in the real world ( siacs OMEMO). It is open to debate now, how to continue from here on. One suggestion is to document the current state of siacs OMEMO in a historical XEP and continue development of the protocol in a new one. While starting from scratch offers a lot of new possibilities and allows for a quicker development, it also most definitely implies to completely break compatibility to siacs OMEMO at users expense. XMPP is nearly 20 years old now. I do not believe that we are in a hurry .

I think siacs OMEMO should not get frozen in time in favor of OMEMO-NEXT . Users are easily confused with names, so I fear that two competing but incompatible OMEMOs are definitely not the way to go. On the other hand, a new standard with a new name that serves the exact same use case is also a bad idea. OMEMO works. Why sould users switch? Instead I’d like to see a smooth transition to a more developer friendly, permissively implementable protocol with broad currency. Already there are OTR and OpenPGP as competitors. We don’t need even more segmentation (let alone the same name for different protocols). I propose to ditch the current official OMEMO XEP in favor of the siacs XEP and from there on go with Andreas’ suggestion, which allows both libsignal as well as Olm to be used simultaneously. This allows permissive implementations of OMEMO, drives development of a permissively licensed conversion algorithm and does not keep users standing in the rain.

To conclude my reflections: Users who use OMEMO will use OMEMO in two or three years. It is up to the community to decide, whether it will be frozen “historical” siacs OMEMO, or collectively developed, smoothly transitioned and unified OMEMO.

Obrigado pelo seu tempo.

This entry was posted on Wednesday, June 28th, 2017 at 12:08 am and is filed under englisch, xmpp. Você pode acompanhar qualquer resposta a essa entrada por meio do feed RSS 2.0. Responses are currently closed, but you can trackback from your own site.

Comentários estão fechados.

vanitasvitae's blog is proudly powered by WordPress.

Allied Universal Teams Up with PlanetRisk to Offer GSOC Service and Product Offering.

SANTA ANA, Calif. and CONSHOHOCKEN, Pa., Feb. 27, 2018 (GLOBE NEWSWIRE) -- Allied Universal, a leading facility services company and the largest security force in North America, has teamed up with PlanetRisk to offer organizations an enterprise risk Software as a Service platform to stay informed of threats to their operation in real time. The service will be offered as a stand-alone solution or as part of the Allied Universal Global Security Operations Center as a Service (GSOCaaS) product suite available in the company’s Monitoring and Response Center (MaRC), based in Richardson, Texas.

“Enterprises that go with PlanetRisk will gain a ‘single pane of glass’ common operating picture that combines multiple data feeds into one GSOC interface,” says Ty Richmond, Allied Universal President, Integrated Security Solutions and Technology. “Our support of custom integration with this product along with analyst services allows us to offer fully-managed situational awareness to help customers prepare for and prevent operational threats, minimize risk for employees and protect assets.”

PlanetRisk delivers actionable intelligence by accelerating the aggregation of global data to interpret connections between seemingly unconnected events. On a real-time basis, PlanetRisk monitors all client assets (offices, facilities, manufacturing, supply chain, travelers, executives, vehicles, aircraft) and provides alerts and notifications when an event or incident occurs. Using big data and analytics, the cloud-based platform identifies threat patterns and risk warnings relevant to clients’ business operations. These early indicators provide customers the ability to create informed response mitigation plans.

“Partnering with Allied Universal gives PlanetRisk’s product suite unprecedented exposure to Fortune 500 companies across North America,” said Paul McQuillan, President and CEO of PlanetRisk. “We are incredibly excited that our CSX platform will power Allied Universal’s GSOCaaS with situational awareness on a global scale, and rich contextual analysis with PlanetRisk’s 10,000+ data layers.”

PlanetRisk’s flexible third-party integration architecture enables CSX to work with other platforms for a seamless workflow process. The web-based CSX product, accessible anywhere, is supported through a custom dashboard compatible with desktop or mobile devices. Allied Universal clients can have their systems monitored 24x7x365 via GSOC operators and analysts dedicated at the MaRC, a client’s site or PlanetRisk’s Global Intelligence Operations Center. These resources are critical to the analysis, reporting, and communication of critical events as well as to managing all physical and operational information work flow.

PlanetRisk recently signed a contract worth up to $79 million over five years to provide the U. S. Department of Homeland Security (DHS) Office of Cybersecurity and Communications with Program Management Support. Learn more about PlanetRisk at planetrisk, and Allied Universal’s GSOC services at aus/gsocaas.

Allied Universal, a leading facility services company and the largest security force in North America with over 150,000 employees, provides unparalleled security services and solutions. With headquarters in Santa Ana, Calif., and Conshohocken, Pa., Allied Universal combines people and technology to deliver evolving, tailored solutions that allow our clients to focus on their core business. An unrelenting focus on clients’ success creates partnerships rooted in quality and value, and is supported by experience gained from being in business for over 60 years. Through our people and leading services, systems and solutions…Allied Universal is there for you. For more information, please visit aus.

Postagens recentes.

Postagens recentes.

My GSoC Journey.

For the love of GSoC and Python.

Regarding Payoneer, taxes for Indian students.

MAJOR NEWS.

Skip down to the last parts of this post if you’ve read it before.

Excerpts from the GSoC mailing list (before we were warned for off-topic discussion) -:

Payoneer does not issue prepaid cards in India because of a RBI directive. The bank transfer facility allows for transfer as USD or INR. For transfer as INR, the charges are $3 + 3% of the transaction amount per transaction – this amounts to.

$150 for three transactions. For transfer as USD, the charges are flat $15 per transaction – amounting to $45. One needs to check with their bank regarding any extra charges, forex rate charges, service tax, etc.

Clearly, transfer as USD is the best option at this time.

Apparently, there is some confusion regarding the transfer fees. The FAQ and pricing page at Payoneer says that the fees are $0. If someone could clarify this, please post a comment!

EDIT: For those who have questions, please refer to the comments thread of this post. Nissim, head of community at Payoneer, has decided to lend us a helping hand.

SECOND EDIT: This chat with the Payoneer representative that I had a while ago should clear everything -:

Bella: Hello and welcome to Payoneer Customer Support.

Bella: Before we proceed, please provide me with the answer to your security question:

Bella: What was the name of your first pet?

Bella: Thank you.

Bella: You wish to switch to a USD transfer?

Bella: The fee for the USD transfer is $15 per transfer.

Pritish: Yes, I’d mistakenly selected INR.

Pritish: Wait, I had a doubt regarding this.

Pritish: Sending a page link from Payoneer to you, gimme a min.

Pritish: This page says that the fee for USD transfer is $0.

Pritish: I live in India and this is regarding my stipend for Google summer of code.

Bella: Let me look into this for you.

Bella: Please hold one moment.

Bella: I see, you are affiliated with Google Summer of Code and therefore the fee setup is different than usual. There is no flat fee for the transfers apart from the conversion rates that apply for certain transfers.

Bella: You wish to use a USD transfer instead?

Pritish: So if I transfer as USD, the only charges I will have are those relating to exchange rates and other associated fees at my bank, correct? Nothing from Payoneer’s side?

Bella: Yes, correct.

Pritish: Please do set my transfer mode to USD. Obrigado!

Bella: We will transfer your request to the relevant department and keep you updated via email.

Pritish: Right, thank you.

Bella: Are you still to use the same bank account?

Pritish: Indeed, I am.

Bella: Okay. Obrigado. We will keep you updated and let you know once this is done.

Bella: Is there anything else I can help you with?

Pritish: This was it, thank you so much!

So, in conclusion, I have an account at HDFC bank – to clarify, they charge the following -:

The forex rate, let us call this the base rate. Some percentage of the base rate as conversion fees. Now from the money that is deducted by 1 and 2, 12.5% is charged on this difference as service tax.

Transfer as USD is *still* the winner .

I am posting a link to a blog regarding the tax issue. Apparently, stipends are exempt from taxes, and we need to declare exemption.

Conclusão.

Payoneer recently conducted an experiment with me as their recipient to see which transfer mode would be more beneficial to students residing in India. They sent money through two transactions, one in SWIFT/USD mode and one in INR mode. Long story short, INR mode yielded around Rs 200 extra for the same transaction amount. For larger amounts, such as those distributed by Google, the difference could be larger. It may or may not depend on the bank your account is linked to, but so far, I’ve found that very few banks have been favourable in USD mode (such as IDBI Bank). Most banks, SBI in particular, and surprisingly, even HDFC (experiment confirms for HDFC, since I’m an HDFC account holder) is better off with INR. So whatever you do, choose carefully!