[guardian-dev] Fwd: Open Source Collective is Hiring Maintainers

[Hans-Christoph Steiner]

 Forwarded Message 
Subject: Open Source Collective is Hiring Maintainers
Date: Wed, 01 Mar 2023 21:16:41 +
From: Open Source Collective 
To: h...@eds.org

view online
[https://opencollective.com/opensource/updates/open-source-collective-is-hiring-maintainers]

Open Source Collective logo
[https://res.cloudinary.com/opencollective/image/fetch/h_96,c_fill/f_png/https%3A%2F%2Fopencollective-production.s3.us-west-1.amazonaws.com%2F97017710-a90f-11e9-b6fb-2bbe7128f780.png]
https://opencollective.com/opensource


OPEN SOURCE COLLECTIVE

[https://opencollective.com/opensource]



OPEN SOURCE COLLECTIVE IS HIRING MAINTAINERS

by Benjamin Nickolls [https://opencollective.com/benjam]
Open Source Collective is now able to hire maintainers, full or part-time,
including benefits and healthcare, to work on projects with sufficient financial
support.

Open Source Collective exists to promote a sustainable and healthy ecosystem and
to sustain open source technology for the future. We take a practical and
additive approach to address the challenges we see in the space, working
alongside others to offer solutions that build on top of their work, or to
provide the foundational services for others to build on top of themselves.

One such challenge we see, which has become inescapably relevant this year, is
that there is still a major hurdle for maintainers to vault, even when they have
adequate financial support.

They lack an employer.

While it's easy to shout 'pay the maintainers', many a maintainer will tell you
that without appropriate healthcare, pension and employment provisions, they
simply can't leave their job to become an independent software developer. This
is where Open Source Collective is stepping in.

Open Source Collective can now employ maintainers on sufficiently funded
projects, including healthcare, benefits, paid annual leave and sick leave as
needed. We can do so across the US and internationally in 75 territories around
the world. Projects will set salaries and appropriate policies for management
for staff (we'll publish guidance for this as needed) while we manage payroll,
withholding and paying appropriate taxes and state/territory contributions. Open
Source Collective will charge a nominal fee for managing employment and pass on
any additional fees from our employment providers.

How do I apply?
Open Source Collective can only offer employment to projects hosted by us, but
our organisation's status enables us to work alongside other organisations and
funding methods. If your project has a sufficient amount of funding, and enough
of those funds are managed through us, we will be able to employ you.

Limits and restrictions
We are a US-based organisation; as such we are able to employ in territories
that are not restricted by US sanctions. In addition, we are limited by our
employment service provider's coverage. That said our coverage is extensive and
growing.

If you're unsure whether you qualify, get in touch using this contact form
[https://opencollective.com/redirect?url=https%3A%2F%2Fx7rwr9qad3h.typeform.com%2Fto%2FDviKzWDF].

 Read more about employment services
[https://docs.oscollective.org/what-we-offer/employment-payroll-and-benefits]
 Contact us
[https://opencollective.com/redirect?url=mailto%3Ahello%40oscollective.org]



Comment
[https://opencollective.com/opensource/updates/open-source-collective-is-hiring-maintainers]

[https://opencollective.com/static/images/email/logo-email-foo...@2x.png]
https://opencollective.com

We can do great things together

To unsubscribe from notifications of new updates from this collective, click
here
[https://opencollective.com/email/unsubscribe/hans%40eds.org/opensource/collective.update.published/a797dcc9ee7058d0c7db0cb50dcf0af1b350f89ebd4dc66767661e4936aa99ac3638bb76fdb22d7ac61c85a619c04d5feb375fd4cffe2f9a5401353616f35479]

You can also follow us on Twitter [https://twitter.com/OpenCollect] or come chat
with us on our public Slack channel [https://slack.opencollective.com].

Made with ❤️ from all over the world
[https://docs.opencollective.com/help/about/team]
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] IETF Hackathon Mar 19-20: come hack on TLS ECH, MASQUE, HTTP Transport Auth, etc.

[Hans-Christoph Steiner]

We've been working in the IETF on standards like HTTP Transport Auth, MASQUE, 
and TLS Encrypted ClientHello (ECH formerly knwon as ESNI).  We'll be hacking 
with the public at the upcoming IETF Hackathon.  We'll be physically present in 
Vienna, there is also an online component.


https://www.ietf.org/how/runningcode/hackathons/113-hackathon/

.hc


--
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] IETF Hackathon Mar 19-20: come hack on TLS ECH, MASQUE,

[Hans-Christoph Steiner]

We've been working in the IETF on standards like HTTP Transport Auth, MASQUE, 
and TLS Encrypted ClientHello (ECH formerly knwon as ESNI).  We'll be hacking 
with the public at the upcoming IETF Hackathon.  We'll be physically present in 
Vienna, there is also an online component.


https://www.ietf.org/how/runningcode/hackathons/113-hackathon/

.hc


--
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] seeking Android/Python contractors for mobile/free software/privacy work

[Hans-Christoph Steiner]

We're looking for self-motivated, free software hackers to work with Guardian 
Project on privacy and internet freedom for mobile devices. Our work is 100% 
free software and we have a steady stream of projects that tie into F-Droid, 
Tor, IPFS, Debian, and censorship circumvention.  We work to support people and 
communities around the world.  This is a flexible, remote position but we also 
like to work in person when possible.


About you:

* Have at least a few years experience with native Android and/or Python.
* Demonstrated the ability to work collaboratively.
* Understand public, free software workflows
* Are proactive and self-directed.
* Fluent in Git.

Bonus points for:

* Ruby/Go/C/Rust skills
* Debian (and derivatives)
* Ansible/Docker/Vagrant/Kubernetes
* Experience with GitLab and its API
* Understanding privacy implications of metadata
* Life experiences that are underrepresented in tech work
* Fluency in more than one language
* User research and UX design
* Blogging and writing

About us:

This is for projects managed by Hans-Christoph Steiner. We work in Vienna, 
Austria so ideally you work in a similar time zone, but that is not a 
requirement. We work in English but our team members speak many languages. Work 
is contract-based but with the possibility to shift into full-time employment in 
the future.


Please reply off-list to account...@at.or.at

.hc

--
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556


OpenPGP_signature
Description: OpenPGP digital signature
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] jobs on GDPR with Max Schrems / NOYB

[Hans-Christoph Steiner]

NOYB is hiring:

https://noyb.eu/en/jobs

Software Developer
https://noyb.eu/wp-content/uploads/2019/09/Onepager_job_tech_vFin.pdf 

We are looking for a second front and backend development of existing and new 
web-based systems (collective redress tools, legal tech, member systems), as 
well as supporting our legal team on technical issues in pending cases.

We are looking forward to your application!

Data Protection Lawyer
https://noyb.eu/wp-content/uploads/2019/09/Onepager_all_lawyers_fin.pdf 

Are you passionate about privacy and digital data protection? Do you aim to 
positively impact the daily privacy of as many citizens as possible, using most 
effective enforcement options? Then you might want to join our legal team to 
fight for digital rights and privacy.
Currently, we are looking for a data protection lawyer to join us in Vienna and 
we are looking forward to your application!


.hc
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] FYI: Code Transparency

[Hans-Christoph Steiner]

Mark Murphy:

On Wed, Jun 30, 2021, at 12:55, Nathan of Guardian wrote:

Thanks for the always thorough and thoughtful updates and analysis, Mark.


Happy to help, and thanks for the kind words!


Wouldn't it be possible to build a library that we include in our apps
that inspects the APK files at runtime on a device, and looks for the
transparency files in the APK, and even checks the hashes. This could be
done as a "App Integrity Check" on first run.


The app packager (Google, Amazon) could remove the code that does that check, 
or at least nerf it. For example, replace:

if (isMyAppOK()) {
   proceed()
} else {
   abandonShip()
}

with:

if (true) {
   proceed()
} else {
   abandonShip()
}

The premise here is that because they have app signing authority, then they 
have the technical capability to modify anything that they want in the App 
Bundle (APK for Amazon). You start to get into the same sort of arms race that 
developers fight and lose with those who try to reverse-engineer apps.

The combination of your proposed library and a robust obfuscation system might 
help prevent bulk modification of apps. That starts to impose other limits 
(e.g., can't use Crashlytics for bug reporting, because then you're uploading 
the de-obfuscation maps to Google). It also won't block a determined attacker 
who is going after a few specific apps (e.g., intelligence agency of a country 
that strong-arms Google into distributing tampered apps).

I think that the library that you propose will almost "fall out of" work to 
create a library for checking the integrity of other apps. Having it probably won't hurt.


Thanks Mark for championing this cause!  Its funny to see after years of F-Droid 
getting criticized for having this model, now Google is forcing it.  And F-Droid 
now supports the reproducible builds requirement for any APK signature type.  I 
think the signature copying is starting to work well enough that we could start 
doing reproducible builds even when the upstream developer isn't trying to.


.hc


--
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Android App Bundles

[Hans-Christoph Steiner]

Michael Carbone via guardian-dev:

On 4/29/21 10:26 AM, Nathan of Guardian wrote:


On 4/29/21 8:52 AM, Mark Murphy wrote:

On Thu, Apr 29, 2021, at 08:47, Abel Luck wrote:

There was some discussion about this almost a year ago
https://lists.mayfirst.org/pipermail/guardian-dev/2020-June/thread.html

However no particular conclusions were reached other than "it sucks."

FWIW:

https://commonsware.com/blog/2020/09/23/uncomfortable-questions-app-signing.html

https://commonsware.com/blog/2020/11/30/initial-responses-uncomfortable-questions.html 



The initial post definitely struck a nerve in the community -- a surprising 
number of developers took it upon themselves to pester Google developer 
relations members on the topic. However, after that late November post, I 
have not seen much on this subject coming out of 


Mountain View. I suspect that I'll be writing another post, perhaps tomorrow, 
pointing out Google I|O sessions that might be of relevance on this subject.



Thanks for resharing these excellent posts, Mark.

"However, policies can change, at any time, for any reason, without warning. 
Or, as some guy in a dark helmet once said 
:


I am altering the deal. Pray I don’t alter it any further."


    I think it is time we speak up about this issue more, if only to get
    some more attention on F-Droid.



I am sharing within Access Now and we will ping EFF since they are likely better 
positioned to publicize and advocate on this topic.


It seems like this requirement to give Google your signing keys and use Android 
App Bundles is partly a push to lock developers into Google Play.  I wonder if 
there are some people working on big tech monopolies that could also push on this?


There is also another important choice we can push here: real, FOSS, privacy 
respecting options like CalyxOS.  Calyx has made huge strides in making 
Google-free Android usable and secure.  And CalyxOS of course builds on key 
projects that we know and love, like F-Droid, microG, Tor, and more.  And key 
apps like Telegram, Tutanota, are available from f-droid.org.


Also, it is important to ensure that APKs remain a viable distribution method 
since they are easy to redistribute, and that keeps the Android ecosystem much 
more flexible than iOS.


.hc

--
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] node.js advice needed to unstick DeltaChat packaging work

[Hans-Christoph Steiner]

I think DeltaChat is awesome and want to help spread it to more platforms
I can do the Debian packaging work, and help with the flatpak, but I know zero 
about node.js.  Anyone know node.js and want to help unstick packaging DeltaChat 
for Debian/Ubuntu and getting it building on arm64/rpi?


https://github.com/flathub/chat.delta.desktop/issues/48#issuecomment-803315421

.hc

--
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] weird network activity on mobile network

[Hans-Christoph Steiner]

Interesting, thanks for the report.

.hc

Matej Kovacic via guardian-dev:
> Hi,
> 
> maybe this story (which is still ongoing) will be of interest of some
> people around here.
> 
> I a blogging (in Slovenian language, but you can use google Translate)
> about the second largest mobile operator in Slovenia. In short, I have
> noticed they are doing MITM on HTTPS connections and it turned out that
> they are using Secucloud DNS filtering with quite stupid implementation
> - they were sending requests to blacklisted domains through proxy, which
> did MITM with self signed certificate.
> 
> And few days after that I found out that their mobile network has been
> inserting additional HTTP headers: X-MCCMNC with the value “29340”
> (mobile country code and network code) and - oh yes, baby -
> X-Asmp-User-Msisdn, which in fact contained the phone number of the
> subscriber.
> 
> There is much more of course. I would say it is quite fun reading,
> however it is really a bad practice and - my personal opinion - terrible
> incompetence of maintaining their own network.
> 
> Here are the links:
> 
> # https://telefoncek.si/2020/05/12/prestrezanje-v-omrezju-a1/
> # https://telefoncek.si/2020/05/18/nenavadno-dogajanje-v-omrezju-a1/
> # 
> https://telefoncek.si/2020/05/24/poseganje-v-promet-uporabnikov-operaterja-bob/
> 
> 
> If there is an interest, I can try to compile an English version.
> 
> Regards,
> Matej
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] draft blog post: Figuring Out Crowdsourced Translation of Websites

[Hans-Christoph Steiner]

I just wrote up a big blog post about our experience with po4a and
markdown translation.  It is meant to serve both as a reference of how
to approach it, as well as mapping out key issues so we know how to
improve them with future funding.  I'd love feedback before I publish.

https://eighthave.gitlab.io/info/2020/04/23/figuring-out-crowdsourced-translation-of-websites/

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] jitsi-monitor to track basic data about all known public instances

[Hans-Christoph Steiner]

Jonas Smedegaard:
> Quoting Hans-Christoph Steiner (2020-04-06 12:11:05)
>>
>> With everyone needing video conferencing these days, there has been an
>> explosion of public Jitsi Meet instances, which is great to see.  In
>> order to help people choose which one works for them, I have set up
>> "jitsi-monitor", it runs once a day on all known public Jitsi Meet
>> instances and gathers some basic data on them:
>>
>> * configuration including STUN servers, analytics, etc.
>> * TLS settings and connection timing
>> * TCP traceroute
>> * what else?
> 
> Would be helpful so see which versions of each component are served: 
> https://github.com/jitsi/jitsi-meet/issues/4758#issuecomment-615343735

Thanks for the tip!  It seems that the "base" thing is not usually set,
but there is a similar version number in other places in the index.html,
so I added that:

https://gitlab.com/guardianproject/jitsi-monitor/-/commit/9d88572c278caf15861cbada1a3470a170158c76

Once the job finishes, there should be a new "versions" section in the
report.json and HTML:
https://gitlab.com/guardianproject/jitsi-monitor/-/jobs/518420291

.hc


-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] jitsi-monitor to track basic data about all known public instances

[Hans-Christoph Steiner]

Greg Troxel:
> Hans-Christoph Steiner  writes:
> 
>> With everyone needing video conferencing these days, there has been an
>> explosion of public Jitsi Meet instances, which is great to see.  In
>> order to help people choose which one works for them, I have set up
>> "jitsi-monitor", it runs once a day on all known public Jitsi Meet
>> instances and gathers some basic data on them:
>>
>> * configuration including STUN servers, analytics, etc.
>> * TLS settings and connection timing
>> * TCP traceroute
>> * what else?
> 
> To me, the biggest question about a public Jitsi Meet instance would be
> their privacy policy, as well as some hard-to-deal-with notion of
> whether the community believes it.  I understand why e2e crypto is too
> hard for multiparty calls, particularly when there is no authentication
> infrastructure, but because of plaintext at the bridge, the key question
> is how the bridge handles that plaintext.

yes, it would be great to have all this info somewhere, but that's not
the goal of this project.  This is to gather meaningful info that can be
gathered automatically.  Then something can consume that data to make a
nice representation to the user.

> So I'd add to your list (all things that are hard to figure out, and
> perhaps worthy of being on a json endpoint on each server):
> 
>   Does the server publically commit not to log any traffic contents?

This thing already includes the "logging_config.js", but that's not the
webserver config.

>   Where is the server located, in terms of legal jurisdiction?

Using a WHOIS on the domain and an ASN lookup on the IP address, you
could get a pretty good idea of the relevant legal jurisdictions.

>   How is the server hosted, in terms of bare metal in data center, VPS
>   in data center, or someplace else?

IP ownership will cover a lot of these cases.  E.g. if the IP is
allocated to Hetzner, then its probably hosted there.

>  Does the server publically commit not to log any metadata?  Or commit
>  to retain those logs for some limited time?
>
>   Who is the operator of the server?
>
>   Are random people welcome to use it?  Limitations?

These require a person to answer.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] jitsi-monitor to track basic data about all known public instances

[Hans-Christoph Steiner]

Of the free voice/video systems, I only know and use Jitsi Meet.  That's
why I wrote it this way.  Its great to hear there are other options.

.hc

Jonas Smedegaard:
> Quoting Hans-Christoph Steiner (2020-04-06 12:11:05)
>> With everyone needing video conferencing these days, there has been an 
>> explosion of public Jitsi Meet instances, which is great to see.  In 
>> order to help people choose which one works for them, I have set up 
>> "jitsi-monitor", it runs once a day on all known public Jitsi Meet 
>> instances and gathers some basic data on them:
>>
>> * configuration including STUN servers, analytics, etc.
>> * TLS settings and connection timing
>> * TCP traceroute
>> * what else?
> 
> Are you interested only in Jitsi Meet instances?
> 
> If more generally interested in Open standards and Free licensed 
> instances, I can recommend to also try locate services using 
> SylkServer/Janus/Mediasoup/Licode/Medooze/Spreed/BigBlueButton/OpenMeetings, 
> and identify at each _service_ which underlying engine/framework is used 
> to aid in reliability issues.
> 
> Concretely it seems Jiti Meet works reliably only when _all_ 
> participants in a room use a Chromium-based web browser: 
> https://github.com/jitsi/jitsi-meet/issues/475
> 
> My guess is that Jitsi Meet fails to parse SDP data in the 
> standards-compliant "unified" format and only properly handles "plan B" 
> style as used by Chromium-based browsers.  And my guess is that other 
> engines/frameworks perform differently at that.  I am unaware that 
> anyone has tested for this type of problem.
> 
> Matrix instances use Jitsi Meet.
> 
> NextCloud instances use Spreed.
> 
> https://sip2sip.info/ uses SylkServer.
> 
> https://letsmeet.no/ uses Mediasoup.
> 
> 
>  - Jonas
> 
> P.S.  I manitain some notes on the topic at 
> https://source.redpill.dk/media-stream-hosting.git/tree
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] jitsi-monitor to track basic data about all known public instances

[Hans-Christoph Steiner]

Yeah, a UI like that will definitel make sense as the number of
instances grows.  That'll require a server to run it.  This is a quick
and dirty GitLab-CI thing with static files on GitLab Pages.  But this
code should be useful for setting up a compliance checker.

.hc

Abel Luck:
> Nice work Hans!
> 
> Reminds me of the XMPP compliance tester.. which serves a sligthly
> different purpose: list XMPP servers and the XEPs they support and
> suggest ones with secure settings.
> 
> https://compliance.conversations.im/
> 
> Still, could be a nice UI inspiration.  They used to have a list of all
> servers at once, but they removed that, I guess to reduce spam?
> 
> ~abel
> 
> Hans-Christoph Steiner:
>>
>> I forgot to add two things:
>>
>> * This scrapes other sources for the list of instances.  If you want it
>> advertised, then I think you should add it to:
>> https://github.com/jitsi/jitsi-meet/wiki/Jitsi-Meet-Instances  I think
>> you can just edit that page with a GitHub account.  Otherwise, the
>> README lists the places that are scraped, where you can add them:
>> https://gitlab.com/guardianproject/jitsi-monitor#source-lists
>>
>> * This can be run locally to get results based on the local network.  So
>> far, this has only been tested on Debian/buster.  I recommend running
>> this on a throwaway setup, like in Docker or a VM.  If you have FireJail
>> installed, this will run the JavaScript inside of a jail.
>>
>> .hc
>>
>> Hans-Christoph Steiner:
>>>
>>> With everyone needing video conferencing these days, there has been an
>>> explosion of public Jitsi Meet instances, which is great to see.  In
>>> order to help people choose which one works for them, I have set up
>>> "jitsi-monitor", it runs once a day on all known public Jitsi Meet
>>> instances and gathers some basic data on them:
>>>
>>> * configuration including STUN servers, analytics, etc.
>>> * TLS settings and connection timing
>>> * TCP traceroute
>>> * what else?
>>>
>>> This script should also work for people to run on their own network to
>>> choose the closest instance.  The source code is here:
>>> https://gitlab.com/guardianproject/jitsi-monitor
>>>
>>> The results from our runs on GitLab CI are here in very basic HTML
>>> format.  I'd love to see this used by someone who makes nice Javascript
>>> UIs.  There is a full JSON report available there too:
>>> https://guardianproject.gitlab.io/jitsi-monitor/
>>>
>>> .hc
>>>
>>
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] jitsi-monitor to track basic data about all known public instances

[Hans-Christoph Steiner]

I forgot to add two things:

* This scrapes other sources for the list of instances.  If you want it
advertised, then I think you should add it to:
https://github.com/jitsi/jitsi-meet/wiki/Jitsi-Meet-Instances  I think
you can just edit that page with a GitHub account.  Otherwise, the
README lists the places that are scraped, where you can add them:
https://gitlab.com/guardianproject/jitsi-monitor#source-lists

* This can be run locally to get results based on the local network.  So
far, this has only been tested on Debian/buster.  I recommend running
this on a throwaway setup, like in Docker or a VM.  If you have FireJail
installed, this will run the JavaScript inside of a jail.

.hc

Hans-Christoph Steiner:
> 
> With everyone needing video conferencing these days, there has been an
> explosion of public Jitsi Meet instances, which is great to see.  In
> order to help people choose which one works for them, I have set up
> "jitsi-monitor", it runs once a day on all known public Jitsi Meet
> instances and gathers some basic data on them:
> 
> * configuration including STUN servers, analytics, etc.
> * TLS settings and connection timing
> * TCP traceroute
> * what else?
> 
> This script should also work for people to run on their own network to
> choose the closest instance.  The source code is here:
> https://gitlab.com/guardianproject/jitsi-monitor
> 
> The results from our runs on GitLab CI are here in very basic HTML
> format.  I'd love to see this used by someone who makes nice Javascript
> UIs.  There is a full JSON report available there too:
> https://guardianproject.gitlab.io/jitsi-monitor/
> 
> .hc
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] jitsi-monitor to track basic data about all known public instances

[Hans-Christoph Steiner]

With everyone needing video conferencing these days, there has been an
explosion of public Jitsi Meet instances, which is great to see.  In
order to help people choose which one works for them, I have set up
"jitsi-monitor", it runs once a day on all known public Jitsi Meet
instances and gathers some basic data on them:

* configuration including STUN servers, analytics, etc.
* TLS settings and connection timing
* TCP traceroute
* what else?

This script should also work for people to run on their own network to
choose the closest instance.  The source code is here:
https://gitlab.com/guardianproject/jitsi-monitor

The results from our runs on GitLab CI are here in very basic HTML
format.  I'd love to see this used by someone who makes nice Javascript
UIs.  There is a full JSON report available there too:
https://guardianproject.gitlab.io/jitsi-monitor/

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Fwd: NitroPad: Secure Laptop With Unique Tamper Detection

[Hans-Christoph Steiner]

glad to hear that the FP3 is good!  They are making progress then.  I
like the FP2 well enough, but its buggy.  Partially, I assume that's
because it is hard to make a device with easy to swap out parts.  Its a
bummer they don't have Fairphone Open for FP3, but I think they are
overwhelmed with Android integration work, so its better to have one
solid ROM than a Play and an Open where neither are solid.

.hc

Abel Luck:
> Agreed with both of you.
> 
> I still use my librem daily. I said I wouldn't buy another, but that's
> cause I plan to use it for a long time until hopefuly there is a good
> alternative. And I guess if my Librem drowned today I would buy another :S.
> 
> I plug in my own keyboard, and can get non-USBC hubs for things like
> ethernet. But screen size and ram.. there are limits to the tradeoffs
> I'll make.
> 
> The FP3 is not that bad tbh. Everyone in my household has one now!
> 
> ~abel
> 
> Devrandom:
>> Agreed, ergonomics are definitely not top-notch, and I hope there's an
>> iteration that improves things.  However, for development and Qubes I
>> need 32GB.  That, together with the freedom aspect trumps other
>> considerations.
>>
>> On Thu, Jan 16, 2020 at 2:29 AM Hans-Christoph Steiner
>>  wrote:
>>>
>>>
>>> I hear you, and I've similar things from others. Fairphone is in a
>>> similar boat.  I think we need to compare apples to apples here: what
>>> Nitrokey, Librem and Fairphone are trying to do is important, no other
>>> providers are doing those things better.  Things like:
>>>
>>> * true free software support
>>> * hardware switches
>>> * repairability
>>> * conflict-free minerals
>>>
>>> .hc
>>>
>>> Abel Luck:
>>>> I have a Purism Librem v3 (the 13" model) and I have to say I am not
>>>> very happy with it.
>>>>
>>>> From a privacy pov, it's nice. ME can be disabled manually. The hardware
>>>> switches are very handy. Rather than ship binary blobs for the bluetooth
>>>> driver, they left that feature out, not compromising. Which I like.
>>>>
>>>> However from an ergonomics/usability pov, I am quite dissatisfied. When
>>>> I say the keyboard is bad, I'm not a keyboard snob. It truly is just a
>>>> bad keyboard, I really dread having to go on the road and use the
>>>> keyboard for any length of time. The trackpad quality is also very low.
>>>>
>>>> Also the laptop comes with a usb c port, which is basically useless as
>>>> it doesn't support thunderbolt, which means no adapter for ethernet or
>>>> external displays. Waste of a port!
>>>>
>>>> I wouldn't buy another Librem :/
>>>>
>>>> That NitroPad looks interesting, but the deal breaker for me is the
>>>> 1366x768 px screen. So small! 1920x1080 is the minimum I would ever get
>>>> in a laptop again.
>>>>
>>>> ~abel
>>>>
>>>> Devrandom:
>>>>> This is a Lenovo.  The Purism laptop goes to 32GB and has hardware kill
>>>>> switches.  It also has secure boot with the Nitrokey and the TPM option,
>>>>> but I didn't try it (yet).
>>>>>
>>>>> On Wed, Jan 8, 2020 at 4:19 AM Hans-Christoph Steiner <
>>>>> h...@guardianproject.info> wrote:
>>>>>
>>>>>>
>>>>>> Looks like quite a nice laptop setup for privacy:
>>>>>>
>>>>>>
>>>>>>  Forwarded Message 
>>>>>> Subject: NitroPad: Secure Laptop With Unique Tamper Detection
>>>>>> Date: Tue, 7 Jan 2020 10:25:13 +0100
>>>>>> From: Nitrokey 
>>>>>> Reply-To: Nitrokey 
>>>>>> To: Hans-Christoph Steiner 
>>>>>>
>>>>>> Deutsche Übersetzung ist hier:
>>>>>>
>>>>>> https://sendy.nitrokey.com/l/DYw4PK9oeKpCQ4HCJ3sHVA/d891PlpQflj763CzcTeLrLCQ/2drgzRE7oneOhHNyMnMe8g
>>>>>>
>>>>>> Dear Nitrokey supporters!
>>>>>>
>>>>>> Do you think your computer hardware is secure? Can you rule out that in
>>>>>> your absence no one has manipulated your computer? In a world, where
>>>>>> most users do not have any real control over their hardware and have to
>>>>>> blindly trust the security promises of vendors, NitroPad unlocks a
>>>>>> refreshingly new security experience. NitroPad X230

Re: [guardian-dev] Fwd: NitroPad: Secure Laptop With Unique Tamper Detection

[Hans-Christoph Steiner]

I hear you, and I've similar things from others. Fairphone is in a
similar boat.  I think we need to compare apples to apples here: what
Nitrokey, Librem and Fairphone are trying to do is important, no other
providers are doing those things better.  Things like:

* true free software support
* hardware switches
* repairability
* conflict-free minerals

.hc

Abel Luck:
> I have a Purism Librem v3 (the 13" model) and I have to say I am not
> very happy with it.
> 
> From a privacy pov, it's nice. ME can be disabled manually. The hardware
> switches are very handy. Rather than ship binary blobs for the bluetooth
> driver, they left that feature out, not compromising. Which I like.
> 
> However from an ergonomics/usability pov, I am quite dissatisfied. When
> I say the keyboard is bad, I'm not a keyboard snob. It truly is just a
> bad keyboard, I really dread having to go on the road and use the
> keyboard for any length of time. The trackpad quality is also very low.
> 
> Also the laptop comes with a usb c port, which is basically useless as
> it doesn't support thunderbolt, which means no adapter for ethernet or
> external displays. Waste of a port!
> 
> I wouldn't buy another Librem :/
> 
> That NitroPad looks interesting, but the deal breaker for me is the
> 1366x768 px screen. So small! 1920x1080 is the minimum I would ever get
> in a laptop again.
> 
> ~abel
> 
> Devrandom:
>> This is a Lenovo.  The Purism laptop goes to 32GB and has hardware kill
>> switches.  It also has secure boot with the Nitrokey and the TPM option,
>> but I didn't try it (yet).
>>
>> On Wed, Jan 8, 2020 at 4:19 AM Hans-Christoph Steiner <
>> h...@guardianproject.info> wrote:
>>
>>>
>>> Looks like quite a nice laptop setup for privacy:
>>>
>>>
>>>  Forwarded Message 
>>> Subject: NitroPad: Secure Laptop With Unique Tamper Detection
>>> Date: Tue, 7 Jan 2020 10:25:13 +0100
>>> From: Nitrokey 
>>> Reply-To: Nitrokey 
>>> To: Hans-Christoph Steiner 
>>>
>>> Deutsche Übersetzung ist hier:
>>>
>>> https://sendy.nitrokey.com/l/DYw4PK9oeKpCQ4HCJ3sHVA/d891PlpQflj763CzcTeLrLCQ/2drgzRE7oneOhHNyMnMe8g
>>>
>>> Dear Nitrokey supporters!
>>>
>>> Do you think your computer hardware is secure? Can you rule out that in
>>> your absence no one has manipulated your computer? In a world, where
>>> most users do not have any real control over their hardware and have to
>>> blindly trust the security promises of vendors, NitroPad unlocks a
>>> refreshingly new security experience. NitroPad X230 [1] is significantly
>>> more secure than normal computers. With NitroPad, you'll have more
>>> control over your hardware than ever before while maintaining ease of use.
>>>
>>> Features
>>>
>>> Tamper Detection Through Measured Boot
>>>
>>> Thanks to the combination of the open source solutions Coreboot [2],
>>> Heads [3] and Nitrokey USB hardware, you can verify that your laptop
>>> hardware has not been tampered with in transit or in your absence
>>> (so-called evil maid attack). The integrity of the TPM, the firmware and
>>> the operating system is effectively checked by a separate Nitrokey USB
>>> key. Simply connect your Nitrokey to the NitroPad while booting and a
>>> green LED on the Nitrokey will show that your NitroPad has not been
>>> tampered with. If the LED should turn red one day, it indicates a
>>> manipulation.
>>>
>>> Deactivated Intel Management Engine
>>>
>>> Vulnerable and proprietary low-level hardware parts are disabled to make
>>> the hardware more robust against advanced attacks.
>>>
>>> The Intel Management Engine (ME) is some kind of separate computer
>>> within all modern Intel processors (CPU). The ME acts as a master
>>> controller for your CPU and has broad access to your computer (system
>>> memory, screen, keyboard, network). Intel controls the code of the ME
>>> and severe vulnerabilities have been found in the ME enabling local and
>>> remote attacks. Therefore ME can be considered as a backdoor and has
>>> been deactivated in NitroPad.
>>>
>>> Preinstalled Ubuntu Linux With Full-Disk Encryption
>>>
>>> NitroPad ships with a preinstalled Ubuntu Linux 18.04 LTS [4] with
>>> full-disk encryption. Ubuntu is one of the most popular, stable and
>>> easiest to use Linux distributions. Switching from Windows to Linux has
>>> never been easier.
>>>
>>> Optio

[guardian-dev] Fwd: NitroPad: Secure Laptop With Unique Tamper Detection

[Hans-Christoph Steiner]

Looks like quite a nice laptop setup for privacy:


 Forwarded Message 
Subject: NitroPad: Secure Laptop With Unique Tamper Detection
Date: Tue, 7 Jan 2020 10:25:13 +0100
From: Nitrokey 
Reply-To: Nitrokey 
To: Hans-Christoph Steiner 

Deutsche Übersetzung ist hier:
https://sendy.nitrokey.com/l/DYw4PK9oeKpCQ4HCJ3sHVA/d891PlpQflj763CzcTeLrLCQ/2drgzRE7oneOhHNyMnMe8g

Dear Nitrokey supporters!

Do you think your computer hardware is secure? Can you rule out that in
your absence no one has manipulated your computer? In a world, where
most users do not have any real control over their hardware and have to
blindly trust the security promises of vendors, NitroPad unlocks a
refreshingly new security experience. NitroPad X230 [1] is significantly
more secure than normal computers. With NitroPad, you'll have more
control over your hardware than ever before while maintaining ease of use.

Features

Tamper Detection Through Measured Boot

Thanks to the combination of the open source solutions Coreboot [2],
Heads [3] and Nitrokey USB hardware, you can verify that your laptop
hardware has not been tampered with in transit or in your absence
(so-called evil maid attack). The integrity of the TPM, the firmware and
the operating system is effectively checked by a separate Nitrokey USB
key. Simply connect your Nitrokey to the NitroPad while booting and a
green LED on the Nitrokey will show that your NitroPad has not been
tampered with. If the LED should turn red one day, it indicates a
manipulation.

Deactivated Intel Management Engine

Vulnerable and proprietary low-level hardware parts are disabled to make
the hardware more robust against advanced attacks.

The Intel Management Engine (ME) is some kind of separate computer
within all modern Intel processors (CPU). The ME acts as a master
controller for your CPU and has broad access to your computer (system
memory, screen, keyboard, network). Intel controls the code of the ME
and severe vulnerabilities have been found in the ME enabling local and
remote attacks. Therefore ME can be considered as a backdoor and has
been deactivated in NitroPad.

Preinstalled Ubuntu Linux With Full-Disk Encryption

NitroPad ships with a preinstalled Ubuntu Linux 18.04 LTS [4] with
full-disk encryption. Ubuntu is one of the most popular, stable and
easiest to use Linux distributions. Switching from Windows to Linux has
never been easier.

Optional: Preinstalled Qubes OS For Highest Security Requirements

Instead of Ubuntu Linux, on request you can get your NitroPad with
preinstalled Qubes OS 4.0 [5] and full-disk encryption.

Qubes OS enables highly isolated working by means of virtual machines
(VM). A separate VM is started for each application or workspace. This
approach isolates applications and processes much more than conventional
operating systems. Qubes OS keeps your system secure, even if a
vulnerability has been exploited in one of the software applications
used. Example: If your PDF viewer or web browser has been successfully
attacked, the attacker cannot compromise the rest of the system and will
be locked out once the VM is closed.

In addition, separate virtual workspaces can be used, such as an offline
workspace for secret data and an online workspace for communication.
NitroPad with Qubes OS is technically similar to SINA clients (for
governments), but remains transparent thanks to open source. Qubes OS is
for users who want maximum security.

Keys Under Your Control

All individual cryptographic keys are generated directly on the NitroPad
exclusively during installation and are not stored by us. However, all
individual keys can be replaced by you. Unlike "Secure Boot", the keys
for securing the operating system remain under your control and do not
depend on the consent of the vendor.

Nitrokey USB Key Included

NitroPad comes with a Nitrokey Pro 2 [6] or a Nitrokey Storage 2 [7].
Their security features include for example email encryption (PGP,
S/MIME), secure server administration (SSH) and two-factor
authentication through one-time passwords (OTP). The Nitrokey Storage 2
additionally contains an encrypted mass storage with hidden volumes.

Professional ThinkPad Hardware

Based on Lenovo ThinkPad X230, the hardware finish and robustness meet
professional quality standards. The famous ThinkPad keyboard with
background lighting and TrackPoint allows comfortable working. The used
laptops have been refurbished.

Out-of-the-Box User Experience

With NitroPad, you don't need to take care of opening the hardware
casing to flash the BIOS chip, installing and configuring Linux, or
pairing the Nitrokey Pro/Storage. We do this work for you. The Nitrokey
is already configured with your NitroPad so that it can be used for
tamper detection without any further configuration effort.

Security Conscious Shipping

To make it more difficult to intercept and manipulate your NitroPad, the
NitroPad and the Nitrokey USB key can be shipped in two separate
shipments 

[guardian-dev] AndroidX ProxyController for SOCKS proxying of WebViews

[Hans-Christoph Steiner]

Apparently, it is now possible to use SOCKS proxies for WebViews:


 Forwarded Message 
Subject: Re: #26764 [Applications/Orbot]: HTTP proxy bug in Orbot
16.0.2-RC-1
Date: Sun, 22 Dec 2019 02:35:51 -
From: Tor Bug Tracker & Wiki 
Reply-To: tor-assista...@torproject.org

#26764: HTTP proxy bug in Orbot 16.0.2-RC-1
+--
 Reporter:  soren@… |  Owner:  n8fr8
 Type:  defect  | Status:  assigned
 Priority:  Medium  |  Milestone:
Component:  Applications/Orbot  |Version:
 Severity:  Normal  | Resolution:
 Keywords:  |  Actual Points:
Parent ID:  #24215  | Points:
 Reviewer:  |Sponsor:
+--

Comment (by soren@…):

 With the upcoming 3.3 release of Privacy Browser, I have switched the code
 to use the new AndroidX ProxyController, which allows Android's WebViews
 to use SOCKS proxies.

 
https://developer.android.com/reference/androidx/webkit/ProxyConfig.Builder.html#addProxyRule(java.lang.String)

 As such, this is not longer an issue for my app.  But it may still be a
 problem for some other people.

--
Ticket URL:

Tor Bug Tracker & Wiki 
The Tor Project: anonymity online

___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Trip Report: Reproducible Builds Summit

[Hans-Christoph Steiner]

I was at the 5th Reproducible Builds Summit this past week, representing
mostly Android topics.  I attended the first two, so it was nice to see
that there has been some real progress in the past few years of work.
My main focus was working with an Apache/Maven developer on implementing
the "buildinfo" spec for publishing reproducible Java JAR builds to
Maven Central and other Maven repositories.  Maven repositories are
central to the whole Android and Java ecosystems as the primary means of
getting libraries.  We used the jtorctl library to prototype how this
system will look when using the Maven, Gradle, and Bazel buildsystems.

Given the results of our brief work, we should have something working
and deployed this year.  And there is already a Maven plugin for
publishing the "buildinfo" files.  So it should be easy to start getting
libraries to publish these to Maven Central and other Maven
repositories.  Then the Apache/Maven Developer plans to push Apache
Software Foundation to require reproducible builds for all its official
Java releases.

If you want to help with this effort, you can start publishing buildinfo
files with your library, or try rebuilding libraries based on published
buildinfo files to test whether there is enough information to reproduce
the builds.

.hc


-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] TLSv1.3 adoption seems to have dropped 16% in the past month

[Hans-Christoph Steiner]

After a steady increase in adoption over the past year, TLSv1.3 adoption
just took a pretty big drop.  Anyone have any data or news about why?

Here's a chart that seems to show that servers have been reducing the
max supported TLS version from 1.3 to 1.2:
https://kjur.github.io/www/sslpulsetrend/index.html#proto

.hc


-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] NDK r21 Long Term Support for Tor

[Hans-Christoph Steiner]

Matthew Finkel:
> On 2019-11-13 17:17, Hans-Christoph Steiner wrote:
>> http://feedproxy.google.com/~r/blogspot/hsDu/~3/cY4BiZhHZbc/introducing-ndk-r21-our-first-long-term.html
>>
>> I'm thinking its probably worth switching to this beta so we can stick
>> to that release for a long time.
> 
> That seems reasonable. My initial concern is whether we can mix NDK
> versions, like compiling tor (for TorServices) with r21 and Firefox with
> r17, but we can test that and make sure it works.

As far as I know, those binaries are already building with something
newer than r17b, so that would be something to check regardless of
whether NDK r20 or r21 is used for the Maven Central artifacts.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] anti-tracking fashion research

[Hans-Christoph Steiner]

There has been a number of fun designs that confuse AI tracking.  It
would be great to have these on t-shirts.  For example:

https://www.theguardian.com/technology/2017/jan/04/anti-surveillance-clothing-facial-recognition-hyperface

And now this new one, with some solid work towards making this kind of
thing actually work in the real world:
https://www.theregister.co.uk/2019/11/04/tshirt_ai_cameras/

Nathan, that team is at Northeastern University, maybe you could get
them to partner on a line of privacy fashion!  I could see a jumpsuit
made with that pattern!

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] NDK r21 Long Term Support for Tor

[Hans-Christoph Steiner]

http://feedproxy.google.com/~r/blogspot/hsDu/~3/cY4BiZhHZbc/introducing-ndk-r21-our-first-long-term.html

I'm thinking its probably worth switching to this beta so we can stick to that 
release for a long time.

.hc___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Fwd: [Pearg] Fwd: New Version Notification for draft-rao-pitfol-00.txt

[Hans-Christoph Steiner]

https://guardianproject.info/2017/01/30/how-can-we-learn-without-watching/

https://guardianproject.info/2017/06/08/tracking-usage-without-tracking-people/

https://f-droid.org/2019/04/15/privacy-preserving-analytics.html

.hc

David Oliver:
> Hans, I think tracking this internet draft is "square one".  IETF has an
> official comment policy, open to all.   If GP have write-ups of any work
> we've done in this area, we can point this team in that direction.  I can
> help - if it's easier - just transmit this info when I meet the author at
> IETF in mid-Nov.
> 
> 
> David M. Oliver | david@g uardianproject.info |
> http://g <http://olivercoady.com>uardianproject.info | @davidmoliver | +1
> 970 368 2366
> 
> 
> On Tue, Nov 5, 2019 at 12:59 PM Hans-Christoph Steiner <
> h...@guardianproject.info> wrote:
> 
>>
>> In general, I think removing personal information from server logs is
>> something to get involved in. How are you thinking of working with them?
>>
>> .hc
>>
>> David Oliver:
>>> Would we have any interest in standards-related discussion relative to
>>> server log data anonymization?   See below for some new work starting up
>> on
>>> this topic in IETF.
>>>
>>> Dave
>>>
>>> David M. Oliver | david@g uardianproject.info |
>>> http://g <http://olivercoady.com>uardianproject.info | @davidmoliver |
>> +1
>>> 970 368 2366
>>>
>>>
>>> -- Forwarded message -
>>> From: Shivan Kaul Sahib 
>>> Date: Mon, Nov 4, 2019 at 5:57 PM
>>> Subject: [Pearg] Fwd: New Version Notification for
>> draft-rao-pitfol-00.txt
>>> To: 
>>> Cc: , 
>>>
>>>
>>> Hi all,
>>>
>>> Sandeep Rao from Grab, Ryan Guest from Salesforce and I have been
>>> discussing log data classification shortly after Ryan's presentation on
>> log
>>> data privacy at the IETF 104 PEARG meeting. This draft is a first attempt
>>> at exploring ways in which applications can tag log fields as containing
>>> personal information for further anonymization/processing.
>>>
>>> Sandeep will be presenting this draft at the upcoming IETF Singapore
>> PEARG
>>> meeting.
>>>
>>> -- Forwarded message -
>>> From: 
>>> Date: Mon, Nov 4, 2019 at 2:44 PM
>>> Subject: New Version Notification for draft-rao-pitfol-00.txt
>>> To: Ryan Guest , Sandeep Rao <
>>> sandeeprao.i...@gmail.com>, Shivan Sahib 
>>>
>>>
>>>
>>> A new version of I-D, draft-rao-pitfol-00.txt
>>> has been successfully submitted by Shivan Sahib and posted to the
>>> IETF repository.
>>>
>>> Name:   draft-rao-pitfol
>>> Revision:   00
>>> Title:  Personal Information Tagging for Logs (PITFoL)
>>> Document date:  2019-11-04
>>> Group:  Individual Submission
>>> Pages:  6
>>> URL:
>> https://www.ietf.org/internet-drafts/draft-rao-pitfol-00.txt
>>> Status: https://datatracker.ietf.org/doc/draft-rao-pitfol/
>>> Htmlized:   https://tools.ietf.org/html/draft-rao-pitfol-00
>>> Htmlized:   https://datatracker.ietf.org/doc/html/draft-rao-pitfol
>>>
>>>
>>> Abstract:
>>>Software applications typically generate a large amount of log data
>>>in the course of their operation in order to help with monitoring,
>>>troubleshooting, etc.  However, like all data generated and operated
>>>upon by software systems, logs can contain information sensitive to
>>>users.  Personal data identification and anonymization in logs is
>>>thus crucial to ensure that no personal data is being inadvertently
>>>logged and retained which would make the logging application run
>>>afoul of laws around storing private information.  This document
>>>focuses on exploring mechanisms to specify personal or sensitive data
>>>in logs, to enable any server collecting, processing or analyzing
>>>logs to identify personal data and thereafter, potentially enforce
>>>any redaction.
>>>
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>>
>>>
>>> ___
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>
>>
>> --
>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Fwd: [Pearg] Fwd: New Version Notification for draft-rao-pitfol-00.txt

[Hans-Christoph Steiner]

In general, I think removing personal information from server logs is
something to get involved in. How are you thinking of working with them?

.hc

David Oliver:
> Would we have any interest in standards-related discussion relative to
> server log data anonymization?   See below for some new work starting up on
> this topic in IETF.
> 
> Dave
> 
> David M. Oliver | david@g uardianproject.info |
> http://g uardianproject.info | @davidmoliver | +1
> 970 368 2366
> 
> 
> -- Forwarded message -
> From: Shivan Kaul Sahib 
> Date: Mon, Nov 4, 2019 at 5:57 PM
> Subject: [Pearg] Fwd: New Version Notification for draft-rao-pitfol-00.txt
> To: 
> Cc: , 
> 
> 
> Hi all,
> 
> Sandeep Rao from Grab, Ryan Guest from Salesforce and I have been
> discussing log data classification shortly after Ryan's presentation on log
> data privacy at the IETF 104 PEARG meeting. This draft is a first attempt
> at exploring ways in which applications can tag log fields as containing
> personal information for further anonymization/processing.
> 
> Sandeep will be presenting this draft at the upcoming IETF Singapore PEARG
> meeting.
> 
> -- Forwarded message -
> From: 
> Date: Mon, Nov 4, 2019 at 2:44 PM
> Subject: New Version Notification for draft-rao-pitfol-00.txt
> To: Ryan Guest , Sandeep Rao <
> sandeeprao.i...@gmail.com>, Shivan Sahib 
> 
> 
> 
> A new version of I-D, draft-rao-pitfol-00.txt
> has been successfully submitted by Shivan Sahib and posted to the
> IETF repository.
> 
> Name:   draft-rao-pitfol
> Revision:   00
> Title:  Personal Information Tagging for Logs (PITFoL)
> Document date:  2019-11-04
> Group:  Individual Submission
> Pages:  6
> URL:https://www.ietf.org/internet-drafts/draft-rao-pitfol-00.txt
> Status: https://datatracker.ietf.org/doc/draft-rao-pitfol/
> Htmlized:   https://tools.ietf.org/html/draft-rao-pitfol-00
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-rao-pitfol
> 
> 
> Abstract:
>Software applications typically generate a large amount of log data
>in the course of their operation in order to help with monitoring,
>troubleshooting, etc.  However, like all data generated and operated
>upon by software systems, logs can contain information sensitive to
>users.  Personal data identification and anonymization in logs is
>thus crucial to ensure that no personal data is being inadvertently
>logged and retained which would make the logging application run
>afoul of laws around storing private information.  This document
>focuses on exploring mechanisms to specify personal or sensitive data
>in logs, to enable any server collecting, processing or analyzing
>logs to identify personal data and thereafter, potentially enforce
>any redaction.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Seeking Jetpack Compose Security Concerns

[Hans-Christoph Steiner]

Hey Mark,

Thanks for all your work tracking and pushing stuff like this!  Sounds
like you're already raising some key points.  I haven't looked at this
at all yet.  I must say: such a drastic change sounds scary in terms of
the amount of work it'll take to move apps.  It is really warranted to
ditch the whole View structure?

.hc

Mark Murphy:
> As you may be aware, Google is working on Jetpack Compose, a next-generation 
> UI toolkit for Android apps, effectively replacing the existing View-based 
> system that we have been using since the beginning. Barring unexpected 
> technical problems, I expect Compose to be Google's Android UI focus for the 
> next decade.
> 
> Since it is being developed in the open, and since it is still early in 
> developer previews, we have a wonderful opportunity to try to ensure that 
> this toolkit handles security-related scenarios well.
> 
> If you find security-related concerns in Compose, file issues! If you know of 
> security-related concerns in the existing View system, and you want me to try 
> to determine if Compose suffers from similar problems, reach out!
> 
> 
> 
> As an example, we use FLAG_SECURE to have a window block screenshots and 
> screencasts. However, Android lacks any concept of window inheritance or 
> ownership, so you have to put FLAG_SECURE on each window that needs to be 
> secured. Unfortunately, Google created lots of windows without giving us any 
> opportunity to add that flag, so we cannot readily secure our menus, Spinner 
> and similar drop-downs, toasts, and so on. See 
> https://github.com/commonsguy/cwac-security/blob/master/docs/FLAGSECURE.md 
> for more on that.
> 
> As it turns out, Compose also creates windows, and it presently does not give 
> us the ability to add FLAG_SECURE to them. So, I filed issues for that:
> 
> https://issuetracker.google.com/issues/143778148
> https://issuetracker.google.com/issues/143778149
> 
> Next weekend, I plan to look at text entry in Compose and confirm that we 
> have a way of avoiding String objects, so passphrases can be zero'd out and 
> we don't have plaintext passphrases floating around our heap unnecessarily.
> 
> That's the sort of thing that we need to try to identify. In theory, since 
> Compose is shipped as libraries, this sort of thing can be improved later 
> (unlike framework classes that are baked into the firmware). In practice, 
> large code bases tend to ossify, and so the longer problems linger, the less 
> likely it is that we will be able to get them fixed.
> 
> Thanks in advance for any suggestions or support!
> 
> --
> Mark Murphy (a Commons Guy)
> https://commonsware.com | https://github.com/commonsguy
> https://commonsware.com/blog | https://twitter.com/commonsguy
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Fwd: Your organization's usage has exceeded its limits

[Hans-Christoph Steiner]

Time to move more stuff off of Transifex to Weblate:


 Forwarded Message 
Subject: Your organization's usage has exceeded its limits
Date: Fri, 04 Oct 2019 21:26:26 -
From: Transifex Notifications 
To: h...@guardianproject.info

Your word count limit has been exceeded


Looks like you’ve been busy with translations! Unfortunately though,
you’ve also outgrown your current plan. To be sure your Transifex
service isn’t interrupted, please upgrade to a plan with a higher word
count limit.

[ Upgrade Subscription
https://www.transifex.com/guardianproject/subscription/ ]


If you have any questions about our plans, or need a plan bigger than
what’s showing on our subscription page, that’s no problem. Just email
us at supp...@transifex.com and we’ll get back to you.
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Heads up: Orfox "RIP" EOL is coming, moving to TBA!

[Hans-Christoph Steiner]

Congrats!  The perfect end to the Orfox project: its now merged into
offical Tor Browser.

This test case sounds like a great thing to run on one of those device
testing services: install the last working version of Orfox, then update
it with that one.

.hc

Nathan of Guardian:
> We will be officially announcing the end of Orfox this week, by
> releasing a final update to the 1.2 million active users of Orfox on
> Google Play and F-Droid. We haven't kept Orfox up to date with Firefox
> or Tor Browser fixes, so we must bring it to a forced end. Besides, TBA
> is looking good and working great, so anyone who wants Tor Browser on
> Android should use it.
> 
> This "OrfoxRIP" app will replace the existing Orfox app:
> https://github.com/guardianproject/Orfox/releases/tag/Orfox-Final-RIP-v16
> 
> If you have Orfox still installed, please try installing it over what
> you have, and let me know if you have any issues.
> 
> Download the APK:
> https://github.com/guardianproject/Orfox/releases/download/Orfox-Final-RIP-v16/Orfox-Final-RIP-v16.apk
> 
> Otherwise, you can see the discussion and design work on this ticket:
> https://trac.torproject.org/projects/tor/ticket/29955
> 
> Thanks!
> 
> +n
> 
> 
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Autocrypt?

[Hans-Christoph Steiner]

I think the idea is essential if we want to maintain e2e email going
forward.  Otherwise, it'll die and be replaced by the messenging silos
from Signal to Whatsapp.  I haven't looked at the details of it, so I
can't speak to whether its trustworthy.  But there are good people involved.

.hc

Richard Z:
> Hi,
> 
> wondering, what are the opinions regarding Autocrypt here?
>   https://autocrypt.org/
> 
> I don't see it as great progress that a protocol that has been
> designed with a builtin MITM weakness is rolled out?
> 
> Richard
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] GitHub Sponsors

[Hans-Christoph Steiner]

GitHub has a new beta program called "Sponsors" which is a donation
service.  It is a closed beta, so you have to apply to join.  I applied:

https://help.github.com/en/articles/about-github-sponsors-for-sponsored-developers

They also support quite a few other donation services like Patreon and
Liberapay.  I added our Liberapay to a few projects to try it out.  Here
are the options:
https://help.github.com/en/articles/displaying-a-sponsor-button-in-your-repository

@n8fr8: do you want to add the Patreon that you setup?  Basically, its a
FUNDING.yml file at the root of each github repo.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] IOCipher 64-bit support

[Hans-Christoph Steiner]

Ok, I'm confused.  The 0.4 release also fails on 32-bit x86 emulators,
so I guess there is something else going on.  The Android Studio test
setup has always been brittle...

So I'm going to call this a 0.5 release, and we'll see how it works for you.

.hc

Hans-Christoph Steiner:
> 
> So there are now 64-bit builds and the test suite passes on 64-bit
> emulators.  But now it fails on 32-bit, so I'm working on it still.
> 
> .hc
> 
> zoki:
>> Great!
>>
>> NDK is r19.
>>
>> Have splitted Application32 and Application64 like in android sqlcipher.
>> And one small change:
>> APP_PROJECT_PATH := $(shell pwd)
>> APP_BUILD_SCRIPT := $(APP_PROJECT_PATH)/jni/Android.mk
>> APP_ABI := armeabi-v7a x86
>> APP_PLATFORM := android-21
>> APP_STL := c++_static
>> APP_CFLAGS := -D_FILE_OFFSET_BITS=32
>>
>> APP_PROJECT_PATH := $(shell pwd)
>> APP_BUILD_SCRIPT := $(APP_PROJECT_PATH)/jni/Android.mk
>> APP_ABI := x86_64 arm64-v8a
>> APP_PLATFORM := android-21
>> APP_STL := c++_static
>> APP_CFLAGS := -D_FILE_OFFSET_BITS=64
>>
>> Did also change in JNIHelp.cpp from int -> intptr_t (now it's only a
>> warning)
>> char* ret = (char*) strerror_r(errnum, buf, buflen);
>> if (((intptr_t)ret) == 0) {
>> // POSIX strerror_r, success
>> return buf;
>> } else if (((intptr_t)ret) == -1) {
>>
>> But can't get past #include  in readlink.
>>
>> Zorans-iMac-2:IOCipher zoki$ $ANDROID_NDK_HOME/ndk-build
>>
>> Android NDK: Found platform level in ./project.properties. Setting
>> APP_PLATFORM to android-21.
>>
>> [arm64-v8a] Compile++  : iocipher <= JniConstants.cpp
>>
>> [arm64-v8a] Compile++  : iocipher <= JNI_OnLoad.cpp
>>
>> [arm64-v8a] Compile++  : iocipher <= JNIHelp.cpp
>>
>> jni/JNIHelp.cpp:268:17: warning: cast to 'char *' from smaller integer type
>> 'int' [-Wint-to-pointer-cast]
>>
>> char* ret = (char*) strerror_r(errnum, buf, buflen);
>>
>> ^
>>
>> 1 warning generated.
>>
>> [arm64-v8a] Compile++  : iocipher <= readlink.cpp
>>
>> In file included from jni/readlink.cpp:18:
>>
>> jni/readlink.h:17:10: fatal error: 'string' file not found
>>
>> #include 
>>
>>  ^~~~
>>
>> 1 error generated.
>>
>> make: *** [obj/local/arm64-v8a/objs/iocipher/readlink.o] Error 1
>>
>> Zorans-iMac-2:IOCipher zoki$
>>
>> On Wed, Jun 19, 2019 at 12:03 PM Hans-Christoph Steiner <
>> h...@guardianproject.info> wrote:
>>
>>>
>>> How about posting about your build issue, and we can get started on the
>>> process now :)
>>>
>>> .hc
>>>
>>> zoki:
>>>> That would be great, thanks. Trying to build it now, but have some
>>> problems
>>>> :/
>>>>
>>>> On Wed, Jun 19, 2019 at 11:36 AM Hans-Christoph Steiner <
>>>> h...@guardianproject.info> wrote:
>>>>
>>>>>
>>>>> Yes, we'll get that going hopefully this month.
>>>>>
>>>>> .hc
>>>>>
>>>>> zoki:
>>>>>> Hello!
>>>>>>
>>>>>> Is there any plan to release 64-bit version which will be required
>>> after
>>>>>> 1.8.2019?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>>>>
>>>>>
>>>>> --
>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>>>>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>>>> ___
>>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>>>
>>>>
>>>
>>> --
>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>>
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] IOCipher 64-bit support

[Hans-Christoph Steiner]

So there are now 64-bit builds and the test suite passes on 64-bit
emulators.  But now it fails on 32-bit, so I'm working on it still.

.hc

zoki:
> Great!
> 
> NDK is r19.
> 
> Have splitted Application32 and Application64 like in android sqlcipher.
> And one small change:
> APP_PROJECT_PATH := $(shell pwd)
> APP_BUILD_SCRIPT := $(APP_PROJECT_PATH)/jni/Android.mk
> APP_ABI := armeabi-v7a x86
> APP_PLATFORM := android-21
> APP_STL := c++_static
> APP_CFLAGS := -D_FILE_OFFSET_BITS=32
> 
> APP_PROJECT_PATH := $(shell pwd)
> APP_BUILD_SCRIPT := $(APP_PROJECT_PATH)/jni/Android.mk
> APP_ABI := x86_64 arm64-v8a
> APP_PLATFORM := android-21
> APP_STL := c++_static
> APP_CFLAGS := -D_FILE_OFFSET_BITS=64
> 
> Did also change in JNIHelp.cpp from int -> intptr_t (now it's only a
> warning)
> char* ret = (char*) strerror_r(errnum, buf, buflen);
> if (((intptr_t)ret) == 0) {
> // POSIX strerror_r, success
> return buf;
> } else if (((intptr_t)ret) == -1) {
> 
> But can't get past #include  in readlink.
> 
> Zorans-iMac-2:IOCipher zoki$ $ANDROID_NDK_HOME/ndk-build
> 
> Android NDK: Found platform level in ./project.properties. Setting
> APP_PLATFORM to android-21.
> 
> [arm64-v8a] Compile++  : iocipher <= JniConstants.cpp
> 
> [arm64-v8a] Compile++  : iocipher <= JNI_OnLoad.cpp
> 
> [arm64-v8a] Compile++  : iocipher <= JNIHelp.cpp
> 
> jni/JNIHelp.cpp:268:17: warning: cast to 'char *' from smaller integer type
> 'int' [-Wint-to-pointer-cast]
> 
> char* ret = (char*) strerror_r(errnum, buf, buflen);
> 
> ^
> 
> 1 warning generated.
> 
> [arm64-v8a] Compile++  : iocipher <= readlink.cpp
> 
> In file included from jni/readlink.cpp:18:
> 
> jni/readlink.h:17:10: fatal error: 'string' file not found
> 
> #include 
> 
>      ^~~~
> 
> 1 error generated.
> 
> make: *** [obj/local/arm64-v8a/objs/iocipher/readlink.o] Error 1
> 
> Zorans-iMac-2:IOCipher zoki$
> 
> On Wed, Jun 19, 2019 at 12:03 PM Hans-Christoph Steiner <
> h...@guardianproject.info> wrote:
> 
>>
>> How about posting about your build issue, and we can get started on the
>> process now :)
>>
>> .hc
>>
>> zoki:
>>> That would be great, thanks. Trying to build it now, but have some
>> problems
>>> :/
>>>
>>> On Wed, Jun 19, 2019 at 11:36 AM Hans-Christoph Steiner <
>>> h...@guardianproject.info> wrote:
>>>
>>>>
>>>> Yes, we'll get that going hopefully this month.
>>>>
>>>> .hc
>>>>
>>>> zoki:
>>>>> Hello!
>>>>>
>>>>> Is there any plan to release 64-bit version which will be required
>> after
>>>>> 1.8.2019?
>>>>>
>>>>> Thanks!
>>>>>
>>>>>
>>>>> ___
>>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>>>
>>>>
>>>> --
>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>>>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>>> ___
>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>>
>>>
>>
>> --
>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] IOCipher 64-bit support

[Hans-Christoph Steiner]

So here are the first 64-bit builds, totally untested.  I'd appreciate
some testing:
https://gitlab.com/eighthave/iocipher/-/jobs/245769076

You can download the binaries by clicking the "Download" button in the
upper right on each job.  I'm going to start testing now, so there will
be more updates there.

.hc

zoki:
> Hi!
> 
> Anything new on 64-bit version?
> 
> On Wed, Jun 19, 2019 at 12:21 PM zoki  wrote:
> 
>> Great!
>>
>> NDK is r19.
>>
>> Have splitted Application32 and Application64 like in android sqlcipher.
>> And one small change:
>> APP_PROJECT_PATH := $(shell pwd)
>> APP_BUILD_SCRIPT := $(APP_PROJECT_PATH)/jni/Android.mk
>> APP_ABI := armeabi-v7a x86
>> APP_PLATFORM := android-21
>> APP_STL := c++_static
>> APP_CFLAGS := -D_FILE_OFFSET_BITS=32
>>
>> APP_PROJECT_PATH := $(shell pwd)
>> APP_BUILD_SCRIPT := $(APP_PROJECT_PATH)/jni/Android.mk
>> APP_ABI := x86_64 arm64-v8a
>> APP_PLATFORM := android-21
>> APP_STL := c++_static
>> APP_CFLAGS := -D_FILE_OFFSET_BITS=64
>>
>> Did also change in JNIHelp.cpp from int -> intptr_t (now it's only a
>> warning)
>> char* ret = (char*) strerror_r(errnum, buf, buflen);
>> if (((intptr_t)ret) == 0) {
>> // POSIX strerror_r, success
>> return buf;
>> } else if (((intptr_t)ret) == -1) {
>>
>> But can't get past #include  in readlink.
>>
>> Zorans-iMac-2:IOCipher zoki$ $ANDROID_NDK_HOME/ndk-build
>>
>> Android NDK: Found platform level in ./project.properties. Setting
>> APP_PLATFORM to android-21.
>>
>> [arm64-v8a] Compile++  : iocipher <= JniConstants.cpp
>>
>> [arm64-v8a] Compile++  : iocipher <= JNI_OnLoad.cpp
>>
>> [arm64-v8a] Compile++  : iocipher <= JNIHelp.cpp
>>
>> jni/JNIHelp.cpp:268:17: warning: cast to 'char *' from smaller integer
>> type 'int' [-Wint-to-pointer-cast]
>>
>> char* ret = (char*) strerror_r(errnum, buf, buflen);
>>
>> ^
>>
>> 1 warning generated.
>>
>> [arm64-v8a] Compile++  : iocipher <= readlink.cpp
>>
>> In file included from jni/readlink.cpp:18:
>>
>> jni/readlink.h:17:10: fatal error: 'string' file not found
>>
>> #include 
>>
>>  ^~~~
>>
>> 1 error generated.
>>
>> make: *** [obj/local/arm64-v8a/objs/iocipher/readlink.o] Error 1
>>
>> Zorans-iMac-2:IOCipher zoki$
>>
>> On Wed, Jun 19, 2019 at 12:03 PM Hans-Christoph Steiner <
>> h...@guardianproject.info> wrote:
>>
>>>
>>> How about posting about your build issue, and we can get started on the
>>> process now :)
>>>
>>> .hc
>>>
>>> zoki:
>>>> That would be great, thanks. Trying to build it now, but have some
>>> problems
>>>> :/
>>>>
>>>> On Wed, Jun 19, 2019 at 11:36 AM Hans-Christoph Steiner <
>>>> h...@guardianproject.info> wrote:
>>>>
>>>>>
>>>>> Yes, we'll get that going hopefully this month.
>>>>>
>>>>> .hc
>>>>>
>>>>> zoki:
>>>>>> Hello!
>>>>>>
>>>>>> Is there any plan to release 64-bit version which will be required
>>> after
>>>>>> 1.8.2019?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>>>>
>>>>>
>>>>> --
>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>>>>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>>>> ___
>>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>>>
>>>>
>>>
>>> --
>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>>
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556



signature.asc
Description: OpenPGP digital signature
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] IOCipher 64-bit support

[Hans-Christoph Steiner]

So here are the first 64-bit builds, totally untested.  I'd appreciate
some testing:
https://gitlab.com/eighthave/iocipher/-/jobs/245769076

You can download the binaries by clicking the "Download" button in the
upper right on each job.  I'm going to start testing now, so there will
be more updates there.

.hc

zoki:
> Hi!
> 
> Anything new on 64-bit version?
> 
> On Wed, Jun 19, 2019 at 12:21 PM zoki  wrote:
> 
>> Great!
>>
>> NDK is r19.
>>
>> Have splitted Application32 and Application64 like in android sqlcipher.
>> And one small change:
>> APP_PROJECT_PATH := $(shell pwd)
>> APP_BUILD_SCRIPT := $(APP_PROJECT_PATH)/jni/Android.mk
>> APP_ABI := armeabi-v7a x86
>> APP_PLATFORM := android-21
>> APP_STL := c++_static
>> APP_CFLAGS := -D_FILE_OFFSET_BITS=32
>>
>> APP_PROJECT_PATH := $(shell pwd)
>> APP_BUILD_SCRIPT := $(APP_PROJECT_PATH)/jni/Android.mk
>> APP_ABI := x86_64 arm64-v8a
>> APP_PLATFORM := android-21
>> APP_STL := c++_static
>> APP_CFLAGS := -D_FILE_OFFSET_BITS=64
>>
>> Did also change in JNIHelp.cpp from int -> intptr_t (now it's only a
>> warning)
>> char* ret = (char*) strerror_r(errnum, buf, buflen);
>> if (((intptr_t)ret) == 0) {
>> // POSIX strerror_r, success
>> return buf;
>> } else if (((intptr_t)ret) == -1) {
>>
>> But can't get past #include  in readlink.
>>
>> Zorans-iMac-2:IOCipher zoki$ $ANDROID_NDK_HOME/ndk-build
>>
>> Android NDK: Found platform level in ./project.properties. Setting
>> APP_PLATFORM to android-21.
>>
>> [arm64-v8a] Compile++  : iocipher <= JniConstants.cpp
>>
>> [arm64-v8a] Compile++  : iocipher <= JNI_OnLoad.cpp
>>
>> [arm64-v8a] Compile++  : iocipher <= JNIHelp.cpp
>>
>> jni/JNIHelp.cpp:268:17: warning: cast to 'char *' from smaller integer
>> type 'int' [-Wint-to-pointer-cast]
>>
>> char* ret = (char*) strerror_r(errnum, buf, buflen);
>>
>> ^
>>
>> 1 warning generated.
>>
>> [arm64-v8a] Compile++  : iocipher <= readlink.cpp
>>
>> In file included from jni/readlink.cpp:18:
>>
>> jni/readlink.h:17:10: fatal error: 'string' file not found
>>
>> #include 
>>
>>  ^~~~
>>
>> 1 error generated.
>>
>> make: *** [obj/local/arm64-v8a/objs/iocipher/readlink.o] Error 1
>>
>> Zorans-iMac-2:IOCipher zoki$
>>
>> On Wed, Jun 19, 2019 at 12:03 PM Hans-Christoph Steiner <
>> h...@guardianproject.info> wrote:
>>
>>>
>>> How about posting about your build issue, and we can get started on the
>>> process now :)
>>>
>>> .hc
>>>
>>> zoki:
>>>> That would be great, thanks. Trying to build it now, but have some
>>> problems
>>>> :/
>>>>
>>>> On Wed, Jun 19, 2019 at 11:36 AM Hans-Christoph Steiner <
>>>> h...@guardianproject.info> wrote:
>>>>
>>>>>
>>>>> Yes, we'll get that going hopefully this month.
>>>>>
>>>>> .hc
>>>>>
>>>>> zoki:
>>>>>> Hello!
>>>>>>
>>>>>> Is there any plan to release 64-bit version which will be required
>>> after
>>>>>> 1.8.2019?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>>>>
>>>>>
>>>>> --
>>>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>>>>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>>>> ___
>>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>>>
>>>>
>>>
>>> --
>>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>>>
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] IOCipher 64-bit support

[Hans-Christoph Steiner]

How about posting about your build issue, and we can get started on the
process now :)

.hc

zoki:
> That would be great, thanks. Trying to build it now, but have some problems
> :/
> 
> On Wed, Jun 19, 2019 at 11:36 AM Hans-Christoph Steiner <
> h...@guardianproject.info> wrote:
> 
>>
>> Yes, we'll get that going hopefully this month.
>>
>> .hc
>>
>> zoki:
>>> Hello!
>>>
>>> Is there any plan to release 64-bit version which will be required after
>>> 1.8.2019?
>>>
>>> Thanks!
>>>
>>>
>>> ___
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>
>>
>> --
>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
>> ___
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] IOCipher 64-bit support

[Hans-Christoph Steiner]

Yes, we'll get that going hopefully this month.

.hc

zoki:
> Hello!
> 
> Is there any plan to release 64-bit version which will be required after
> 1.8.2019?
> 
> Thanks!
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] setting up app store metadata on Weblate with Fastlane

[Hans-Christoph Steiner]

ores. All work integrated into 
> all the related projects. Documentation complete.Estimated Due Date: 
> 7 May 2019  € 2,816.55 ($3,197.25)
> 
> If you can provide documentation for this, we can delay the final report. 
> Otherwise going past the end of the grant date will require a modification. 
> Please let me know what you think is possible  
> 
> Kari 
> 
> -----Original Message-
> From: Hans-Christoph Steiner  
> Sent: Tuesday, May 7, 2019 2:52 AM
> To: k...@iscproject.org
> Cc: 'Fernando Cuervo' 
> Subject: Re: Final milestone
> 
> 
> Hey Kari,
> 
> We have made significant progress on the final milestone, but it does not 
> feel quite complete to me.  I would prefer to have a one month extension, if 
> possible.  I can always write up the report based on what we have completed, 
> if that works better for you.
> 
> .hc
> 
> k...@iscproject.org:
>> Hi Hans,
>>
>>  
>>
>> I hope you are well. I wanted to check in on Milestone 4, which is due 
>> tomorrow. Do you expect being able to submit on time? Please let me know.
>>
>>  
>>
>> Warm regards,
>>
>>  
>>
>> Kari
>>
>>
> 
> --
> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556

___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] auto-generate an app website based on Fastlane/F-Droid metadata

[Hans-Christoph Steiner]

I have been writing a Hugo (static site generator) theme that
automatically generates a website based on the F-Droid/Fastlane metadata
included in an app's source repo.  It is called, unsurprisingly,
fastlane-hugo-theme
https://github.com/guardianproject/fastlane-hugo-theme.  The key idea is
that the metadata provides enough information to build a nice little
website, and GitLab/GitHub Pages makes it really easy to host a site.
This currently supports:

* automatically generates localized sites, based on enabled locales
* GitLab Pages via the standard _.gitlab-ci.yml_ method
* GitHub Pages via [pushing to _gh-pages_
branch](https://gohugo.io/hosting-and-deployment/hosting-on-github/#deployment-of-project-pages-from-your-gh-pages-branch)
* includes all screenshots
* includes feature graphic as header
* includes Title, Short Description, Full Description
* shows badges for F-Droid, Google Play, GitLab, GitHub

The CSS/layout still needs work but I suck at that stuff, so I'd love
help with that part.  Here are some examples generated by this:

* [(source)](https://github.com/guardianproject/ripple) -
https://guardianproject.github.io/ripple
* [(source)](https://gitlab.com/guardianproject/checkey) -
https://guardianproject.gitlab.io/checkey
* coming soon, porting this site: https://guardianproject.github.io/haven

This can also be extended to include more things that can be included in
F-Droid/Fastlane metadata:
* Video
* What's New / Changelogs
* Developer email/name/website
* support for Triple-T Gradle Play Publisher



-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] ALERT: matrix.org compromised, change your IRC passwords

[Hans-Christoph Steiner]

Anyone know anything about the Riot Flatpak package and that process?
I'm not keen to reenable their Debian apt repo given their shoddy
security practices.

While the app isolation of Flatpak sounds great, I have a vague
recollection that some of their repository practices left a lot to be
desired.

.hc

Abel Luck:
> Also remove the signing key:
> 
> $ sudo apt-key del "6FEB 6F83 D48B 9354 7E7D  FEDE E019 6452 48E8 F4A1"
> 
> Hans-Christoph Steiner:
>>
>> Also, more bad news: it seems they kept their GPG signing key for their
>> Debian packages online:
>>
>> https://github.com/matrix-org/matrix.org/issues/364
>>
>> You should immediately remove the riot Debian repo since the install
>> process of deb packages runs things as root.  You can see whether your
>> Debian-ish machine has this repo by doing:
>>
>> $ grep riot.im /etc/apt/sources.list /etc/apt/sources.list.d/*
>>
>> .hc
>>
>> Abel Luck:
>>> Also folks:
>>>
>>> If you still have Riot open and it hasn't logged you out yet, you need
>>> to export your E2E room keys so you don't lose your chat history.
>>>
>>> Click your profile icon in the top left
>>> Choose settings, then security
>>> Click export E2E room keys
>>> Create a new secure password you store in your password manager to
>>> encrypt the keys with
>>> Save them and await for the service to come back so you can import them
>>> again
>>>
>>> ~abel
>>> ___
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>
>>
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] call for help: Java/Gradle advice so we can keep the Android SDK in Debian/buster

[Hans-Christoph Steiner]

This was the tip that finally solved it!  Here's the commit:

https://salsa.debian.org/android-tools-team/android-framework-23/commit/a54bfa906afc9b139f1f6c1a99f76effec301a3e

.hc

Michael Rogers:
> Hi Hans-Christoph,
> 
> As far as I can tell, "javac --patch-module" won't get you where you
> need to go. You could create (perhaps using symlinks) the directory
> structure it's expecting, where the root of the package namespace is
> inside a directory named after the module (e.g.
> src/main/java/java.base/java/lang), which contains a suitable
> module-info.java. But even so, --patch-module would result in the code
> being compiled as a module. You'd then need to modify the rest of the
> toolchain to get every java call to consume that module. I don't know if
> that would even be possible for d8, ProGuard, etc.
> 
> I think what you probably want is for the code to be compiled as Java
> 8-compatible class files. If I've understood the email thread correctly,
> that should be possible, and it's encouraging that adding "--release 8"
> to the compiler options has reduced the scope of the problem to just the
> doclava call. In other words, it did solve the problem for the other
> javac calls.
> 
> This is just a random guess that you've probably already considered, but
> is it possible that the "--release 8" argument that's passed to javac
> isn't being passed to javadoc when running doclava? Perhaps the task
> type for javadoc isn't JavaCompile, for example? (The same might apply
> to -source and -target, I guess - I don't know if sourceCompatibility
> and targetCompatibility set those arguments for javadoc as well as javac.)
> 
> Cheers,
> Michael
> 
> On 31/01/2019 08:25, Hans-Christoph Steiner wrote:
>>
>> The Debian Android Team has been packaging the Android SDK with 100%
>> free software and reproducible builds.  The standard Android SDK
>> binaries from Google have a non-free license and are built with ~13GB of
>> mystery binaries they call "prebuilts".
>>
>> There are two key packages from the Debian Android Tools suite of
>> packages that are currently not going to make it into the buster
>> release.  The core of the problem is that buster is using Java 11, and
>> the Android AOSP code base still uses Java8 and, only in some cases,
>> Java9.  As far as I can tell, just rebuilding the current stretch
>> package or updating will have more or less the same problems there.
>>
>> So far, apo of the Java Team, seamlik of Java/Android teams, and I have
>> all tried quite a bit to get something working.  Now we are banging our
>> heads against details in Java builds that none of us have ever dealt
>> with before.  So we're putting out the call for help, to find someone
>> with this knowledge.  Right now, I think we need to figure out the new
>> Java9 "modules", specifically using the --patch-module= flag to javac
>> and java.
>>
>> Lots more details here:
>> https://lists.debian.org/debian-java/2019/01/msg00052.html
>>

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] localization of app store texts on Weblate

[Hans-Christoph Steiner]

F-Droid and Guardian Project have been working with Weblate to make a
really smooth translation workflow for Android apps, including all the
app store descriptive texts.  There has been much progress the
translation workflow for the app store metadata texts (short
description, full description, "What's New", etc), and we now have a
complete integrated workflow between Google Play, F-Droid, Weblate and
app developers.  The Weblate developers had a key breakthrough that lets
this whole workflow use the same files everywhere. We originally thought
that an extra layer of XLIFF files would be required, with scripts to
convert between XLIFF and the F-Droid/Fastlane/Triple-T formats.

This is part of the "Linguine" cross-project effort to improve
translation workflows, with Weblate being a key component.  Weblate is
tracking related work here:
https://github.com/WeblateOrg/weblate/projects/10#card-13951185

Here are some apps that are now setup with this new workflow:

Checkey
https://hosted.weblate.org/projects/guardianproject/checkey
https://hosted.weblate.org/projects/guardianproject/checkey-metadata
https://gitlab.com/guardianproject/checkey.git (GitLab, not GitHub)

CircleOf6
https://hosted.weblate.org/projects/guardianproject/circleof6
https://hosted.weblate.org/projects/guardianproject/circleof6-metadata
https://github.com/guardianproject/OpenCircle.git

F-Droid
https://hosted.weblate.org/projects/f-droid/f-droid
https://hosted.weblate.org/projects/f-droid/f-droid-metadata/

Haven
https://hosted.weblate.org/projects/guardianproject/haven
https://hosted.weblate.org/projects/guardianproject/haven-metadata
https://github.com/guardianproject/haven.git

Location Privacy
https://hosted.weblate.org/projects/guardianproject/locationprivacy
https://hosted.weblate.org/projects/guardianproject/locationprivacy-metadata
https://github.com/guardianproject/locationprivacy.git

Ripple
https://hosted.weblate.org/projects/guardianproject/ripple
https://hosted.weblate.org/projects/guardianproject/ripple-metadata
https://github.com/guardianproject/ripple.git


I think this Weblate support is worth switching for.  For translating
app store texts on other translation platforms, I recommend keeping the
app store texts in XLIFF format, then using our script to convert to
F-Droid/Fastlane file format and then commit those to the project's git.

Here you can compare the XLIFF (with conversion script):
https://github.com/guardianproject/LocationPrivacy/tree/fad6ec142c65694a7b4cfacd32bb1e57e38c386e/description

to the native F-Droid/Fastlane/Weblate format:
https://github.com/guardianproject/LocationPrivacy/tree/master/metadata

.hc


-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] nice offline use case: roadside assistance app

[Hans-Christoph Steiner]

The devs of this Traveler app says they think about how to keep their app work 
during Internet shutdowns:

https://www.internetsociety.org/blog/2019/02/we-on-this-road-together/___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] call for help: Java/Gradle advice so we can keep the Android SDK in Debian/buster

[Hans-Christoph Steiner]

The Debian Android Team has been packaging the Android SDK with 100%
free software and reproducible builds.  The standard Android SDK
binaries from Google have a non-free license and are built with ~13GB of
mystery binaries they call "prebuilts".

There are two key packages from the Debian Android Tools suite of
packages that are currently not going to make it into the buster
release.  The core of the problem is that buster is using Java 11, and
the Android AOSP code base still uses Java8 and, only in some cases,
Java9.  As far as I can tell, just rebuilding the current stretch
package or updating will have more or less the same problems there.

So far, apo of the Java Team, seamlik of Java/Android teams, and I have
all tried quite a bit to get something working.  Now we are banging our
heads against details in Java builds that none of us have ever dealt
with before.  So we're putting out the call for help, to find someone
with this knowledge.  Right now, I think we need to figure out the new
Java9 "modules", specifically using the --patch-module= flag to javac
and java.

Lots more details here:
https://lists.debian.org/debian-java/2019/01/msg00052.html

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Make connection to socks5 proxy of Orbot using TLS transport

[Hans-Christoph Steiner]

Orbot's SOCKS proxy port is a generic SOCKS proxy, so any TCP or TLS
connection should be able to use it, given the correct config.

.hc

nanu sonu:
> Dear Members,
> 
> I have successfully connected to the socks5proxy of Orbot which is running
> on 127.0.0.1:9050 using TCP transport and also able communicate with my
> server through orbot
> 
> but when I am trying to do the same using TLS transport even not able to
> make a connection to it.
> 
> Can you please confirm me that whether it can be done or not. Your help is
> much appreciated.
> 
> Thank you.
> 
> Regards,
> Nanu
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Ansible playbook for fixing the apt vulnerability

[Hans-Christoph Steiner]

And for more on that topic:
https://guardianproject.info/2019/01/23/use-onions-https-for-software-updates/

.hc

Abel Luck:
> An apt vuln was released today, see these links:
> 
>https://lists.debian.org/debian-security-announce/2019/msg00010.html
>https://security-tracker.debian.org/tracker/CVE-2019-3462
>https://justi.cz/security/2019/01/22/apt-rce.html?
> 
> Since the vulnerability is in the package manager itself, updating is
> non-trivial.
> 
> Here is a small ansible playbook + script to update apt securely. It
> only works on debian stable (stretch).
> 
> https://gist.github.com/abeluck/67525909a17403060cd1722b53d57d00
> 
> commentary: yet another pretty good reason to use HTTPS apt sources by
> default. any chance this vuln will change the zealots' mind?
> 
> ~abel
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] early Facebook investor's take on its hazards

[Hans-Christoph Steiner]

http://rss.slashdot.org/~r/Slashdot/slashdot/~3/15_Sx9ghGLU/mark-zuckerbergs-mentor-shocked-and-disappointedbut-he-has-a-plan

Sounds like he needs to learn about the fediverse.  Promote the fediverse and 
free software rather than subsidizing Facebook as a utility.

.hc___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] UDP ASSOCIATE is not working with orbot using SOCKS5

[Hans-Christoph Steiner]

SOCKS5 apparently supports UDP, jsocks is a SOCKS library used in Orbot.
 Tor does not support UDP.

.hc

nanu sonu:
> Dear Members,
> 
> In send method of below given file clearly mentioning that udp can be sent
> through the SOCKS5 proxy.
> 
> https://github.com/guardianproject/OrbotVPN/blob/master/src/com/runjva/sourceforge/jsocks/protocol/Socks5DatagramSocket.java
> .
> 
> I am totally confused if orbot doesn't support UDP then what is the use of
> this?
> 
> 
> 
> On Wed, Jan 16, 2019 at 3:57 PM nanu sonu  wrote:
> 
>> Dear Abel,
>>
>> When I am routing the UDP traffic through ORBOT VPN ON using  UDP gateway,
>> I am able to route the UDP traffic successfully.I want to Implement the
>> same with ORBOT Socks Proxy without ORBOT VPN
>>
>> Why is it not allowing to do the same in case of ORBOT Socks Proxy.
>>
>> Your help is highly appreciated.
>>
>> On Wed, Jan 16, 2019 at 3:36 PM Abel Luck 
>> wrote:
>>
>>> Unfortunately, Tor only supports TCP traffic. Can you switch to TCP?
>>>
>>> nanu sonu:
 Dear Members,

 Can anyone please help me on this.



 On Thu, Jan 10, 2019 at 5:59 PM nanu sonu  wrote:

>
> Dear Members,
>
> I am using orbot to hide the data which is sending from one of my
> application. And my application is using UDP protocol. So as I have
> understood that to send the udp data i have to make a connection with
> server using UDP ASSOCIATE.
>
> For this I have created the tcp connection and made the handshake
> successfully. After that I also sent the UDP ASSOCIATE request but not
> getting any response from the server.
>
>
> I request all the mates that is orbot supports UDP ASSOCIATE. If yes
>>> what
> I am doing wrong in my case.
>
> Please help me out in this regard.
>
> Thanks in advance.
>
> Regards,
> Nanusonu
>


 ___
 List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
 To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

>>>
>>
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Encrypting DNS end-to-end

[Hans-Christoph Steiner]

nice idea:
https://blog.cloudflare.com/encrypting-dns-end-to-end/

.hc___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Orbot 16.0.5-RC-2-tor-0.3.4.9

[Hans-Christoph Steiner]

Its published.

.hc

Nathan of Guardian:
> Today!
> 
> On 12/18/18 12:47 PM, harbrin...@tutanota.com wrote:
>> Dec 14, 2018, 8:08 PM by nat...@guardianproject.info
>>
>>
>> APKs as usual via the Github link below, our
>> https://guardianproject.info/releases
>>  folder, and soon via
>> Google Play
>> and F-Droid.
>>
>>
>> Any ETA for this hitting the guardianproject F-droid repo?
>>
>>
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] encrypted DNS provided by Orbot?

[Hans-Christoph Steiner]

Nathan of Guardian:
> 
> On 12/14/18 6:01 AM, Hans-Christoph Steiner wrote:
>> n8fr8 proposed something along those lines before.
>>
>> If DNS over TLS (DoT) and/or DNS over HTTPS (DoH) get widespread
>> adoption, then we have a new channel for bridge discovery and other
>> tricks.  Google Jigsaw released its Intra app to let older Android
>> versions use DoH.  It is Apache-2.0 licensed, but with proprietary
>> Google Firebase and other libs.  Perhaps we could take that code and
>> include it in Orbot?
>>
>> https://gitlab.com/fdroid/rfp/issues/735
> 
> Happy to consider. I was thinking more about this, and had some
> concerns, specifically with using the DoH provider over Tor, but then
> sending traffic over cleartext.
> 
> We need to ensure we weren't making it possible for the DoH provider to
> deanonymize someone by returning a custom IP via DoH-over-Tor, and then
> looking for who connects to it via cleartext.
> 
> Or perhaps, I am crossing streams here, and this isn't about anonymity,
> only circumvention?

I think we want to consider both anonymity and circumvention. If DoH has
issues, we should be able to focus on DoT.  The way DoH is being rolled
out has some scary centralization issues, i.e. Google making Chrome only
use the Google DNS servers.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] encrypted DNS provided by Orbot?

[Hans-Christoph Steiner]

n8fr8 proposed something along those lines before.

If DNS over TLS (DoT) and/or DNS over HTTPS (DoH) get widespread
adoption, then we have a new channel for bridge discovery and other
tricks.  Google Jigsaw released its Intra app to let older Android
versions use DoH.  It is Apache-2.0 licensed, but with proprietary
Google Firebase and other libs.  Perhaps we could take that code and
include it in Orbot?

https://gitlab.com/fdroid/rfp/issues/735


.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Orbot 16.0.5-RC-1-tor-0.3.4.9

[Hans-Christoph Steiner]

harbrin...@tutanota.com:
> Nov 14, 2018, 3:05 PM by nat...@guardianproject.info:
> 
>> New Orbot 16.0.5 out now on Github,
>> https://guardianproject.info/releases 
>> >  and soon on Play and F-Droid!
>>
> 
> 
> Hi Nathan,  do you know when this is expected to show up on F-Droid,  I only 
> see 16.0.2-RC1 as the latest.  Should we be looking in GuardianProject 
> f-droid repo or the F-droid ones?

The latest stable Orbot release is up on our fdroid repo now.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Google Play offline peer to peer installs beta

[Hans-Christoph Steiner]

Nathan of Guardian:
> 
> On Wed, Oct 24, 2018, at 3:56 AM, Hans-Christoph Steiner wrote:
>>
>> Google has added app swapping to Play.  Seems we weren't so crazy after all. 
>>  
>>
>> http://feedproxy.google.com/~r/blogspot/hsDu/~3/UT0RC4CPQkk/offline-p2p-installs-beta.html
>>
> 
> ...though the goal for this is more about data efficiency, and not app 
> censorship resistance. I assume this won't work in places where Play is 
> blocked, or even where a certain app is not allowed to be distributed.

Seems like they are integrating with other apps to do the nearby swap
services. For example, SHAREit is an officially annointed app for that.
 So that'll certainly work Google/Play is blocked.  But it'll only work
with apps that are in Play, that seems certain.

Seems like they've learned from our example with F-Droid.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Google Play offline peer to peer installs beta

[Hans-Christoph Steiner]

Google has added app swapping to Play.  Seems we weren't so crazy after all.  

http://feedproxy.google.com/~r/blogspot/hsDu/~3/UT0RC4CPQkk/offline-p2p-installs-beta.html

.hc___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Android Emergency Wipe or Shutdown / PanicKit / PanicButton

[Hans-Christoph Steiner]

An nice layer of protection for cases like this is to use app-specific
encrypted containers.  Our IOCipher library provides full protection
including all the metadata (file names, sizes, etc).  It just looks like
one binary blob on disk.  The app key can be wiped a lot quicker than
the FDE key.

The latest versions of Android have some of these features built-in with
the new File-Based Encryption.  That doesn't protect all the metadata
though.

https://source.android.com/security/encryption/file-based

.hc

Peter Prockers via guardian-dev:
> Like any full disk encryption for linux and also android can only be really
> effective if the device is shutdown. This is because:
> 
> - the disk encryption key is in RAM and can be extracted from there (see
> cold boot attack - while I haven't heard about cold boot attacks against
> android, it's better to be careful since an attacker could just keep the
> android connected to power and shielded from any internet and it would
> never shut down
> 
> - the bootup disk encryption password is probably a lot longer and more
> complex than any lockscreen password for reasons of practicality
> 
> Before an Android is taken away there might be enough time for an emergency
> procedure.
> 
> - For example a very long press of some physical key such as the off key
> could result of the disk encryption masterkey (luks header) being wiped and
> the device shut down. That would make any attempts to extract the key from
> RAM as well as brute force attacks against the disk encryption futile. Of
> course some safeguards against accidental wipe would be nice such as being
> able to abort the procedure by having a configurable timeout of a few
> seconds to enter a PIN which aborts.
> 
> - If one is forced to reveal an unlock PIN, one could reveal a PIN which
> actually wipes the encryption masterkey (luks header) and shuts the device
> down.
> 
> - A voice command for triggering the emergency procedure.
> 
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] How to lock, shutdown, wipe phone when grabbed, robbed, theft from hand?

[Hans-Christoph Steiner]

These sounds like too good approaches.  The hard part of all these kinds
of systems is making them foolproof.  Accidentally wiping all your data
is no fun.  The best bet is to use a device that is easily and fully
backed up.  Then wiping it is no big deal.

.hc

Josh Conway:
> Another option could require constant connection with the 'net, over say a
> Tor phone-in server. If the connection isn't present for $time, require
> password. If password isn't typed in, phone reboots and you get 30 chances
> of bootup password.
> 
> That way, it would be hard to attack the tor server. And it would be hard
> to spoof the Tor connection to fake-authenticate. And no BTLE or other
> physical devices needed - those can be stolen anyway by "bad actors".
> 
> On Tue, Aug 14, 2018 at 9:21 PM, Natanael  wrote:
> 
>> Bluetooth proximity sensor, perhaps smartwatch or other BLE device you can
>> hide on you.
>>
>> Let the phone lock down automatically when out of range.
>>
>>
>> Den tis 14 aug. 2018 21:27Peter Prockers via guardian-dev <
>> guardian-dev@lists.mayfirst.org> skrev:
>>
>>> Imagine the phone is currently unlocked and in oneself hand. What if
>>> someone grabs the phone and runs away?
>>>
>>> Ideally I would like to wipe and shutdown the phone unless aborted with a
>>> PIN which timeout after some amount of time.
>>>
>>> But since there is probably not app yet for wipe and shutdown, is there
>>> at least some app which can turn on the lockscreen when a big movement is
>>> detected?
>>>
>>> ___
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>
>>
>> ___
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>
>>
> 
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Gitlab moved to Google Cloud, which blocks Iran, Cuba, etc.

[Hans-Christoph Steiner]

So Gitlab is migrating to Google Cloud Platform (GCP) and that process
means that users in all the US-sanctioned countries (Iran, Cuba, North
Korea, etc) are now blocked by Google.  Anyone know if there is a way to
turn that off?  Or do we need to put pressure on Google again to do what
they did with Google Play?

https://gitlab.com/gitlab-com/migration/issues/649

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] netcipher 2.0.0-beta1

[Hans-Christoph Steiner]

I just posted netcipher 2.0.0-beta1.  It includes only one small change:
remove the bug that prevents NetCipher for URLConnection from working
with TLSv1.3.   Get it from jcenter.

implementation 'info.guardianproject.netcipher:netcipher:2.0.0-beta1'

I suppose it should be called a stable release at this point, I guess
I'm a bit too conservative with version numbers.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556



signature.asc
Description: OpenPGP digital signature
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Orbot / NetCipher sending status newnym for identity

[Hans-Christoph Steiner]

I believe you can do that by choosing a random username/password to the
SOCKS port, but most things need to use HTTP Proxy.  It would be great
to have newnym well supported in NetCipher, but I don't think it
currently is.

.hc

Tim:
> Hey guardian-dev,
> 
> I was hoping someone can point me in the right direction for
> NetCipher/Orbot and the ability for other android applications using
> netcipher to have the ability to issue a new identity.
> 
> I personally like this idea, but I could see how if you had multiple
> applications all with specific use cases for changing identities, it
> could be end up hurting the performance.
> 
> Either way I'd like to see how it could be done, Either from
> implementing in NetCipher or from overriding in a specific application.
> So please correct my following assumptions if they are incorrect.
> 
> From my understanding this file
> NetCipher-repo/libnetcipher/src/info/guardianproject/netcipher/proxy/OrbotHelper.java
> is where we (I) would implement something calling the newIdentity
> function
> orbot-repo/orbotservice/src/main/java/org/torproject/android/service/TorService.java#L1300
> 
> Then once I've created the new identity function called newIdentity in
> OrbotHelper, then I should just be able to call it in the application
> doing something along the lines of OrbotHelper.newIdentity()
> 
> My reasoning behind wanting something like this is for when you have
> multiple-accounts on a singular platform. i.e. Swapping accounts on the
> same Mastodon instance, or swapping Reddit accounts, so then each
> account does not share the same exit node.
> 
> Am I looking in the right places?
> 
> Cheers
> 
> Tim
> 
> 
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Duplex includes an alarming moral lapse

[Hans-Christoph Steiner]

It turns out that Google knew that "people will probably hang up" if
they knew that they were talking to an AI robot.  So they put lots of
effort into deceiving the people receiving the calls.   They added ums
and mm-hmms and pauses to the speech pattern, and tried to use as
natural a voice as possible.

And on top of all that, the problem they are solving is really quite
trivial.  Is it really so hard or time consuming to call to make your
own appointments?  How many of these phone calls do most people make in
a year anyway?

https://www.bloomberg.com/news/articles/2018-05-10/google-grapples-with-horrifying-reaction-to-uncanny-ai-tech

https://www.theverge.com/2018/5/10/17342414/google-duplex-ai-assistant-voice-calling-identify-itself-update

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] nice overview of mobile app tracking ecosystem

[Hans-Christoph Steiner]

Nice overview of trackers, including a shoutout to F-Droid

https://www.buzzfeed.com/nicolenguyen/how-apps-take-your-data-and-sell-it-without-you-even

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] finally setting up direct donations

[Hans-Christoph Steiner]

Hey all,

Since the ISC grant includes work on moving guardianproject.info to a
static site generator, I wanted to include part of that work finally
adding direct donation links to the Website.

I think we should feature Liberapay as the preferred donation method.
Its all free software, there are no fees, the developers receive payment
for their work via Liberapay donations themselves, and it seems to have
very fair terms.  I set up a "team" there for us:

https://liberapay.com/GuardianProject

Then the way it works is that individual Guardian Project developers
create an account, and can request a share of the Team revenue.  Then
its automatically split and paid out accordingly.

Its growing fast, and SecureDrop and F-Droid are already getting
something on it:
https://liberapay.com/explore/teams

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Telegram founder pledges 1 million dollars to fund proxy servers to beat Russian censorship

[Hans-Christoph Steiner]

Nathan of Guardian:
> 
> 
> On 04/18/2018 10:40 AM, Hans-Christoph Steiner wrote:
>>
>> Shall we reach out to them about the Pluggable Transports lib?
>>
>> https://meduza.io/en/news/2018/04/17/telegram-founder-pledges-1-million-dollars-to-fund-proxy-servers-to-beat-russian-censorship
> 
> Sounds like a plan... was also thinking about at least implementing it,
> and NetCipher (Tor works just fine in Russa still) in the FOSS version
> of Telegram that is on F-Droid. It already supports SOCKS proxying, so
> we'd just prompt the user to auto-set it if Orbot is installed.

That sounds like a good idea.  As for contacting them, I have no leads.
That article just mentions a post on VKontakte, which I've never used.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Telegram founder pledges 1 million dollars to fund proxy servers to beat Russian censorship

[Hans-Christoph Steiner]

Shall we reach out to them about the Pluggable Transports lib?

https://meduza.io/en/news/2018/04/17/telegram-founder-pledges-1-million-dollars-to-fund-proxy-servers-to-beat-russian-censorship

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Android locking down private APIs

[Hans-Christoph Steiner]

So Google is working to lock down more private APIs in both C/C++ and Java:
https://android-developers.googleblog.com/2018/02/improving-stability-by-reducing-usage.html

They ask for bug reports for private APIs that are needed.  We should
file bugs about the proxy support that we need, i.e. the stuff using
reflection to add proxying to WebViews.  I couldn't find an issue in
their tracker, and I didn't know the details enough to file the bug myself.

Anything else?

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] sanitizing PNGs

[Hans-Christoph Steiner]

Donno if you know about the JPEG Redaction lib from ObscuraCam.  Its in
C++, unfortunately, but might have useful approaches in it:

https://github.com/guardianproject/ObscuraCam/tree/master/app/src/main/jni

.hc

Michael Rogers:
> That doesn't look easy, unfortunately. The class seems to be designed to
> work in three stages:
> 
> 1. Load the EXIF data from a file or input stream
> 2. Modify the EXIF data
> 3. Write the modified image to an output stream by reading the input a
> second time and replacing the EXIF segment
> 
> We can't skip to stage 3 because it depends on state that was
> initialised during stage 1. Even if we don't care about the original
> EXIF data, some of the state seems like it would be vital, such as the
> byte order and colour space.
> 
> Maybe we could use a giant BufferedInputStream big enough to hold the
> whole image, allowing us to read the stream twice?
> 
> Cheers,
> Michael
> 
> On 28/03/18 19:43, Hans-Christoph Steiner wrote:
>>
>> Ah cool!  It would be awesome to have the EXIF stripping work on a
>> stream, rather than a file.
>>
>> .hc
>>
>> Michael Rogers:
>>> Fantastic!
>>>
>>> The code is just a single file with minimal Android dependencies, so I
>>> made a quick (untested) Java port:
>>>
>>> https://code.briarproject.org/akwizgran/metadata
>>>
>>> Cheers,
>>> Michael
>>>
>>> On 26/03/18 22:32, Hans-Christoph Steiner wrote:
>>>>
>>>> Turns out Google released an Android Support library that makes it
>>>> trivial to strip EXIF from JPEGs and some RAW formats:
>>>> https://android-developers.googleblog.com/2016/12/introducing-the-exifinterface-support-library.html
>>>>
>>>> I found it via this app in F-Droid:
>>>> https://gitlab.com/juanitobananas/scrambled-exif
>>>>
>>>> This is all it does:
>>>> ExifInterface exifInterface = new ExifInterface(imagePath);
>>>> for (String attribute : getExifAttributes()) {
>>>>   if (exifInterface.getAttribute(attribute) != null) {
>>>> exifInterface.setAttribute(attribute, null);
>>>>   }
>>>> exifInterface.saveAttributes();
>>>>
>>>> .hc
>>>>
>>>> Michael Rogers:
>>>>> Please feel free to use it, I place it in the public domain. I'll have a
>>>>> look at JPEGs next time I'm procrastinating. ;-)
>>>>>
>>>>> (By the way, after sending I noticed a bug: if the file ends with a
>>>>> truncated ancillary chunk, I think the cleaner will loop forever trying
>>>>> to skip to the end of the chunk. Should be easy to fix though.)
>>>>>
>>>>> Cheers,
>>>>> Michael
>>>>>
>>>>> On 13/12/17 13:02, Hans-Christoph Steiner wrote:
>>>>>>
>>>>>> That's awesome!  Feeling inspired to also strip JPEGs? :-)  I think
>>>>>> they're easier.  There is jhead, exiftool, and ObscuraCam's JNI code for
>>>>>> examples.  Can we use this under the GPLv3?
>>>>>>
>>>>>> .hc
>>>>>>
>>>>>> Michael Rogers:
>>>>>>> Hi Hans-Christoph,
>>>>>>>
>>>>>>> I hacked this together based on the PNG specification, which
>>>>>>> distinguishes between ancillary chunks that can be removed without
>>>>>>> affecting the image data, and critical chunks that can't. It's been
>>>>>>> tested on exactly two PNGs so far. :-)
>>>>>>>
>>>>>>> http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Michael
>>>>>>>
>>>>>>> On 12/12/17 16:25, Hans-Christoph Steiner wrote:
>>>>>>>>
>>>>>>>> pyexiftool is just a wrapper for exiftool.  exiftool looks great, but
>>>>>>>> for my use case, I only need to strip all metadata.  It would be much
>>>>>>>> easier if that was in pure Python and pure Java.  perl is a no go on
>>>>>>>> Android.
>>>>>>>>
>>>>>>>> It was dead simple to strip EXIF from JPEG in Python:
>>>>>>>>
>>>>>>>> from pil import Image
>>>>>>>> with open(inpath) as fp:
>>>>>>>>

Re: [guardian-dev] sanitizing PNGs

[Hans-Christoph Steiner]

Sure, loading the whole thing in memory sounds better than dealing with
the filesystem.  The only problem I can there is if its used to process
large images on small mobile devices.

.hc

Michael Rogers:
> That doesn't look easy, unfortunately. The class seems to be designed to
> work in three stages:
> 
> 1. Load the EXIF data from a file or input stream
> 2. Modify the EXIF data
> 3. Write the modified image to an output stream by reading the input a
> second time and replacing the EXIF segment
> 
> We can't skip to stage 3 because it depends on state that was
> initialised during stage 1. Even if we don't care about the original
> EXIF data, some of the state seems like it would be vital, such as the
> byte order and colour space.
> 
> Maybe we could use a giant BufferedInputStream big enough to hold the
> whole image, allowing us to read the stream twice?
> 
> Cheers,
> Michael
> 
> On 28/03/18 19:43, Hans-Christoph Steiner wrote:
>>
>> Ah cool!  It would be awesome to have the EXIF stripping work on a
>> stream, rather than a file.
>>
>> .hc
>>
>> Michael Rogers:
>>> Fantastic!
>>>
>>> The code is just a single file with minimal Android dependencies, so I
>>> made a quick (untested) Java port:
>>>
>>> https://code.briarproject.org/akwizgran/metadata
>>>
>>> Cheers,
>>> Michael
>>>
>>> On 26/03/18 22:32, Hans-Christoph Steiner wrote:
>>>>
>>>> Turns out Google released an Android Support library that makes it
>>>> trivial to strip EXIF from JPEGs and some RAW formats:
>>>> https://android-developers.googleblog.com/2016/12/introducing-the-exifinterface-support-library.html
>>>>
>>>> I found it via this app in F-Droid:
>>>> https://gitlab.com/juanitobananas/scrambled-exif
>>>>
>>>> This is all it does:
>>>> ExifInterface exifInterface = new ExifInterface(imagePath);
>>>> for (String attribute : getExifAttributes()) {
>>>>   if (exifInterface.getAttribute(attribute) != null) {
>>>> exifInterface.setAttribute(attribute, null);
>>>>   }
>>>> exifInterface.saveAttributes();
>>>>
>>>> .hc
>>>>
>>>> Michael Rogers:
>>>>> Please feel free to use it, I place it in the public domain. I'll have a
>>>>> look at JPEGs next time I'm procrastinating. ;-)
>>>>>
>>>>> (By the way, after sending I noticed a bug: if the file ends with a
>>>>> truncated ancillary chunk, I think the cleaner will loop forever trying
>>>>> to skip to the end of the chunk. Should be easy to fix though.)
>>>>>
>>>>> Cheers,
>>>>> Michael
>>>>>
>>>>> On 13/12/17 13:02, Hans-Christoph Steiner wrote:
>>>>>>
>>>>>> That's awesome!  Feeling inspired to also strip JPEGs? :-)  I think
>>>>>> they're easier.  There is jhead, exiftool, and ObscuraCam's JNI code for
>>>>>> examples.  Can we use this under the GPLv3?
>>>>>>
>>>>>> .hc
>>>>>>
>>>>>> Michael Rogers:
>>>>>>> Hi Hans-Christoph,
>>>>>>>
>>>>>>> I hacked this together based on the PNG specification, which
>>>>>>> distinguishes between ancillary chunks that can be removed without
>>>>>>> affecting the image data, and critical chunks that can't. It's been
>>>>>>> tested on exactly two PNGs so far. :-)
>>>>>>>
>>>>>>> http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Michael
>>>>>>>
>>>>>>> On 12/12/17 16:25, Hans-Christoph Steiner wrote:
>>>>>>>>
>>>>>>>> pyexiftool is just a wrapper for exiftool.  exiftool looks great, but
>>>>>>>> for my use case, I only need to strip all metadata.  It would be much
>>>>>>>> easier if that was in pure Python and pure Java.  perl is a no go on
>>>>>>>> Android.
>>>>>>>>
>>>>>>>> It was dead simple to strip EXIF from JPEG in Python:
>>>>>>>>
>>>>>>>> from pil import Image
>>>>>>>> with open(inpath) as fp:
>>>>>>>> in_image = Image.open

[guardian-dev] Signal switches to SQLCipher, with Android KeyStore

[Hans-Christoph Steiner]

So Signal just switched from its custom encrypted store to good ol'
android-database-sqlcipher, which is lovingly maintained by Zetetic:

https://github.com/signalapp/Signal-Android/commit/f36b296e2ed211893835372513da57bb135c52c1

Its a good example for hooking up SQLCipher to the Android KeyStore API.

.hc


-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] sanitizing PNGs

[Hans-Christoph Steiner]

Ah cool!  It would be awesome to have the EXIF stripping work on a
stream, rather than a file.

.hc

Michael Rogers:
> Fantastic!
> 
> The code is just a single file with minimal Android dependencies, so I
> made a quick (untested) Java port:
> 
> https://code.briarproject.org/akwizgran/metadata
> 
> Cheers,
> Michael
> 
> On 26/03/18 22:32, Hans-Christoph Steiner wrote:
>>
>> Turns out Google released an Android Support library that makes it
>> trivial to strip EXIF from JPEGs and some RAW formats:
>> https://android-developers.googleblog.com/2016/12/introducing-the-exifinterface-support-library.html
>>
>> I found it via this app in F-Droid:
>> https://gitlab.com/juanitobananas/scrambled-exif
>>
>> This is all it does:
>> ExifInterface exifInterface = new ExifInterface(imagePath);
>> for (String attribute : getExifAttributes()) {
>>   if (exifInterface.getAttribute(attribute) != null) {
>> exifInterface.setAttribute(attribute, null);
>>   }
>> exifInterface.saveAttributes();
>>
>> .hc
>>
>> Michael Rogers:
>>> Please feel free to use it, I place it in the public domain. I'll have a
>>> look at JPEGs next time I'm procrastinating. ;-)
>>>
>>> (By the way, after sending I noticed a bug: if the file ends with a
>>> truncated ancillary chunk, I think the cleaner will loop forever trying
>>> to skip to the end of the chunk. Should be easy to fix though.)
>>>
>>> Cheers,
>>> Michael
>>>
>>> On 13/12/17 13:02, Hans-Christoph Steiner wrote:
>>>>
>>>> That's awesome!  Feeling inspired to also strip JPEGs? :-)  I think
>>>> they're easier.  There is jhead, exiftool, and ObscuraCam's JNI code for
>>>> examples.  Can we use this under the GPLv3?
>>>>
>>>> .hc
>>>>
>>>> Michael Rogers:
>>>>> Hi Hans-Christoph,
>>>>>
>>>>> I hacked this together based on the PNG specification, which
>>>>> distinguishes between ancillary chunks that can be removed without
>>>>> affecting the image data, and critical chunks that can't. It's been
>>>>> tested on exactly two PNGs so far. :-)
>>>>>
>>>>> http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html
>>>>>
>>>>> Cheers,
>>>>> Michael
>>>>>
>>>>> On 12/12/17 16:25, Hans-Christoph Steiner wrote:
>>>>>>
>>>>>> pyexiftool is just a wrapper for exiftool.  exiftool looks great, but
>>>>>> for my use case, I only need to strip all metadata.  It would be much
>>>>>> easier if that was in pure Python and pure Java.  perl is a no go on
>>>>>> Android.
>>>>>>
>>>>>> It was dead simple to strip EXIF from JPEG in Python:
>>>>>>
>>>>>> from pil import Image
>>>>>> with open(inpath) as fp:
>>>>>> in_image = Image.open(fp)
>>>>>> data = list(in_image.getdata())
>>>>>> out_image = Image.new(in_image.mode, in_image.size)
>>>>>> out_image.putdata(data)
>>>>>> out_image.save(outpath)
>>>>>>
>>>>>> But that broke some PNGs, and the rest were larger in size.
>>>>>>
>>>>>> .hc
>>>>>>
>>>>>> Rick Valenzuela:
>>>>>>> oh, you may already know this, but the previous code keeps a copy of the
>>>>>>> file and metadata. if you want it gone with no copies, you have to add a
>>>>>>> switch to overwrite, e.g.:
>>>>>>>
>>>>>>> ```
>>>>>>> with exiftool.ExifTool() as et:
>>>>>>> et.execute(b'-all=', b'-overwrite_original', b'some.png')
>>>>>>> ```
>>>>>>>
>>>>>>> On 12/12/2017 23:45, Rick Valenzuela wrote:
>>>>>>>> heh, nice --  I just found this:
>>>>>>>>
>>>>>>>> https://github.com/smarnach/pyexiftool
>>>>>>>>
>>>>>>>> Tried it out and it worked great:
>>>>>>>> ```
>>>>>>>> with exiftool.ExifTool() as et:
>>>>>>>>  et.execute(b'-all=', b'some.png')
>>>>>>>> ```
>>>>>>>>
>>>>>>>> On 12/12/2017 19:53, Hans-Christoph Steiner wrote:
>>>>>>>>>
>>>>>>>>> Ah, cool, I thought exiftool only worked with JPEGs.  It seems to work
>>>>>>>>> with just about every image format.  Now the open question is how to
>>>>>>>>> strip all PNG metadata with Python and Java.
>>>>>>>>>
>>>>>>>>> .hc
>>>>>>>>>
>>>>>>>>> Rick Valenzuela:
>>>>>>>>>> does exiftool do what you need?
>>>>>>>>>>
>>>>>>>>>> `exiftool -all= `
>>>>>>>>>>
>>>>>>>>>> On 11/12/2017 17:57, Hans-Christoph Steiner wrote:
>>>>>>>>>>>
>>>>>>>>>>> Anyone know any tools for sanitizing PNGs without touching the
>>>>>>>>>>> compressed image data?  With JPEG it is easy to strip out EXIF with
>>>>>>>>>>> python-pil or many other tools. I haven't found a simple, clean 
>>>>>>>>>>> approach
>>>>>>>>>>> in Python for PNGs.
>>>>>>>>>>>
>>>>>>>>>>> .hc
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] sanitizing PNGs

[Hans-Christoph Steiner]

Turns out Google released an Android Support library that makes it
trivial to strip EXIF from JPEGs and some RAW formats:
https://android-developers.googleblog.com/2016/12/introducing-the-exifinterface-support-library.html

I found it via this app in F-Droid:
https://gitlab.com/juanitobananas/scrambled-exif

This is all it does:
ExifInterface exifInterface = new ExifInterface(imagePath);
for (String attribute : getExifAttributes()) {
  if (exifInterface.getAttribute(attribute) != null) {
exifInterface.setAttribute(attribute, null);
  }
exifInterface.saveAttributes();

.hc

Michael Rogers:
> Please feel free to use it, I place it in the public domain. I'll have a
> look at JPEGs next time I'm procrastinating. ;-)
> 
> (By the way, after sending I noticed a bug: if the file ends with a
> truncated ancillary chunk, I think the cleaner will loop forever trying
> to skip to the end of the chunk. Should be easy to fix though.)
> 
> Cheers,
> Michael
> 
> On 13/12/17 13:02, Hans-Christoph Steiner wrote:
>>
>> That's awesome!  Feeling inspired to also strip JPEGs? :-)  I think
>> they're easier.  There is jhead, exiftool, and ObscuraCam's JNI code for
>> examples.  Can we use this under the GPLv3?
>>
>> .hc
>>
>> Michael Rogers:
>>> Hi Hans-Christoph,
>>>
>>> I hacked this together based on the PNG specification, which
>>> distinguishes between ancillary chunks that can be removed without
>>> affecting the image data, and critical chunks that can't. It's been
>>> tested on exactly two PNGs so far. :-)
>>>
>>> http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html
>>>
>>> Cheers,
>>> Michael
>>>
>>> On 12/12/17 16:25, Hans-Christoph Steiner wrote:
>>>>
>>>> pyexiftool is just a wrapper for exiftool.  exiftool looks great, but
>>>> for my use case, I only need to strip all metadata.  It would be much
>>>> easier if that was in pure Python and pure Java.  perl is a no go on
>>>> Android.
>>>>
>>>> It was dead simple to strip EXIF from JPEG in Python:
>>>>
>>>> from pil import Image
>>>> with open(inpath) as fp:
>>>> in_image = Image.open(fp)
>>>> data = list(in_image.getdata())
>>>> out_image = Image.new(in_image.mode, in_image.size)
>>>> out_image.putdata(data)
>>>> out_image.save(outpath)
>>>>
>>>> But that broke some PNGs, and the rest were larger in size.
>>>>
>>>> .hc
>>>>
>>>> Rick Valenzuela:
>>>>> oh, you may already know this, but the previous code keeps a copy of the
>>>>> file and metadata. if you want it gone with no copies, you have to add a
>>>>> switch to overwrite, e.g.:
>>>>>
>>>>> ```
>>>>> with exiftool.ExifTool() as et:
>>>>> et.execute(b'-all=', b'-overwrite_original', b'some.png')
>>>>> ```
>>>>>
>>>>> On 12/12/2017 23:45, Rick Valenzuela wrote:
>>>>>> heh, nice --  I just found this:
>>>>>>
>>>>>> https://github.com/smarnach/pyexiftool
>>>>>>
>>>>>> Tried it out and it worked great:
>>>>>> ```
>>>>>> with exiftool.ExifTool() as et:
>>>>>>  et.execute(b'-all=', b'some.png')
>>>>>> ```
>>>>>>
>>>>>> On 12/12/2017 19:53, Hans-Christoph Steiner wrote:
>>>>>>>
>>>>>>> Ah, cool, I thought exiftool only worked with JPEGs.  It seems to work
>>>>>>> with just about every image format.  Now the open question is how to
>>>>>>> strip all PNG metadata with Python and Java.
>>>>>>>
>>>>>>> .hc
>>>>>>>
>>>>>>> Rick Valenzuela:
>>>>>>>> does exiftool do what you need?
>>>>>>>>
>>>>>>>> `exiftool -all= `
>>>>>>>>
>>>>>>>> On 11/12/2017 17:57, Hans-Christoph Steiner wrote:
>>>>>>>>>
>>>>>>>>> Anyone know any tools for sanitizing PNGs without touching the
>>>>>>>>> compressed image data?  With JPEG it is easy to strip out EXIF with
>>>>>>>>> python-pil or many other tools. I haven't found a simple, clean 
>>>>>>>>> approach
>>>>>>>>> in Python for PNGs.
>>>>>>>>>
>>>>>>>>> .hc
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Privacy preserving anonymized nginx log config

[Hans-Christoph Steiner]

i'll bet greenhost is ammenable to privacy focused logging configs.

.hc

Tim Schwartz:
> Thanks Micah,
> 
> Yeah I really only think server logs are valuable as debugging, if $$$ is the 
> core concept behind data analytics, then better to do it with a different 
> system than straight server logs anyway. I really like this idea…
> 
>> Fortunately, you can actually get by
>> without keeping any logs, and just turn them on *when you need to debug
>> something* and then *turn them off immediately afterwards*. In this
>> scenario, you are only giving up the possibility of debugging past
>> problems that you cannot reproduce. A worthy sacrifice.
> 
> Though once you are scaling to a few servers or a higher level production 
> environment, turning on / off logs might not be such an easy feat. 
> 
> Is anyone aware of managed hosting systems that have opted for privacy 
> focused logging options? Might be an interesting space to investigate in 
> general.  
> 
> Cheers,
> Tim
> 
> 
>> On Jan 30, 2018, at 9:42 AM, micah  wrote:
>>
>> Tim Schwartz  writes:
>>
>>> This is super helpful btw. Thanks. 
>>>
>>> What do people generally use as a rule of thumb on timing for log
>>> rotations on web servers that are privacy focused?
>>
>> Depends on your threat model, but possibilities are:
>>
>> 1. no logs at all, no rotation needed (when you have a ton of data, this
>> is actually a lot easier)
>>
>> 2. logs only in memory (vulnerable to vampire tap, or preservation
>> orders)
>>
>> 3. rotate stored logs in as short of a time as possible so that you can
>> balance usefulness against being an arbitrarily deputized state agent.
>>
>> when it comes to logging people generally want it for one of these
>> things:
>>
>> 1. surveillance capitalism - monetize visitors behaviors, sell to data
>> brokers, track you across the web, advertising
>>
>> 2. ego vanity - it feels good to know that 500 more people visited your
>> site this month, compared to last month
>>
>> 3. debugging
>>
>> If you can get over the first two (requires a bit of transcendence above
>> the earthly trappings of being human), the third one is really the only
>> reason to have any logs at all. Fortunately, you can actually get by
>> without keeping any logs, and just turn them on *when you need to debug
>> something* and then *turn them off immediately afterwards*. In this
>> scenario, you are only giving up the possibility of debugging past
>> problems that you cannot reproduce. A worthy sacrifice.
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Tracking People Without GPS

[Hans-Christoph Steiner]

https://www.schneier.com/blog/archives/2017/12/tracking_people_5.html

This is fascinating and scary.  I wonder how practical it really is.

.hc ___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] why Firefox needs GCM

[Hans-Christoph Steiner]

I don't follow what SIM cards have to do with GCM?  These same NAT
limitations apply to non-mobile networks.

IPv6 should change the NAT part, but telecoms don't like to give up
control like that.  For example, IPv6 addresses are limitless so there
is no good reason to not just assign a block to each customer.  My ISP
still dynamically allocates IPv6, and that allocation changes every
couple of weeks.  My guess is that they do that so they can still sell
"static IP" as an extra add-on.

And NAT is probably still needed for IPv6 tunnels to IPv4.

.hc

Nathan of Guardian:
> IPv6 changes all this perhaps? Again though, GCM works just fine on any
> random wifi network, too, with tablet devices without sim card receiving
> "pushes". 
> 
> On Fri, Dec 15, 2017, at 04:16 AM, Hans-Christoph Steiner wrote:
>>
>> There is one piece of push services that only big companies can offer,
>> because only they can get the big telecoms to work with them.  Big
>> telecoms use "Carrier Grade NAT" throughout their networks.  NAT means
>> routers have to keep a table of the mappings between the real IP and
>> each client.  That table needs to be garbage collected so it does just
>> grow endlessly.
>>
>> When a TCP connection is open while a device drops off the network or
>> switches to wifi, then the NAT router can't know that the TCP is no
>> longer valid.  So they just have a timeout, they kill all old, inactive
>> TCP connections.  They might do that quite aggresively.
>>
>> Apple and Google then negotiate a deal to give special handling to the
>> TCP connection of their push services.
>>
>> Now, looking back, I've heard this from a number of people but I have
>> never seen data on what this actually looks like.  So maybe this is just
>> conjecture that has never really gone away.  It would be nice to have
>> some real data on this.
>>
>> .hc
>>
>> zoki:
>>> It's not so easy to just open a websocket and forget.
>>>
>>> You are loosing internet connection on a mobile device a lot of time and so
>>> you have to have a good logic behind to detect when your websocket is dead
>>> (pinging) and smart reconnecting logic.
>>>
>>> And if that's not enough you have a problem with background execution
>>> (restriction) and with every new version of Android with keeping wakelocks.
>>> Device will go to sleep and traffic bypasses you.
>>>
>>> Have gone through that path and it was pain :)
>>>
>>> On Thu, Dec 14, 2017, 14:29 Nathan of Guardian <nat...@guardianproject.info>
>>> wrote:
>>>
>>>> Yeah, but this perception always irks me:
>>>>
>>>> "Firefox for Desktop runs its own custom push service called `autopush`
>>>> that keeps long-lived Web Sockets open.  As you surely know, that's not
>>>> viable on a phone"
>>>>
>>>> Holding open a socket that has no data traversing it consumes almost no
>>>> power. GSM is essentially doing this themselves, how else does it work
>>>> on a wifi only device like a tablet?
>>>>
>>>> Perhaps a patch could be written for Fennec/Firefox to use the autopush
>>>> desktop service?
>>>>
>>>>
>>>> On 12/14/2017 03:39 AM, Hans-Christoph Steiner wrote:
>>>>>
>>>>> Finally, an answer to why Firefox needs GCM push services:
>>>>>
>>>> https://forum.f-droid.org/t/making-it-easier-for-f-droid-to-package-mozilla-firefox/1649/13
>>>>>
>>>>>
>>>>>  Forwarded Message 
>>>>> Subject: [F-Droid Forum] [Apps] Making it easier for F-Droid to package
>>>>> Mozilla Firefox
>>>>> Date: Tue, 05 Dec 2017 18:33:53 +
>>>>> From: Nick Alexander <fo...@f-droid.org>
>>>>>
>>>>> [quote="hans, post:12, topic:1649, full:true"]
>>>>> @nalexander about Google Play Services, what is the push stuff used for?
>>>>>  I never understand why Firefox needed its own push services.  But I do
>>>>> understand why push requires GCM on Android.
>>>>> [/quote]
>>>>>
>>>>> This I can answer, 'cuz I built most of this integration for Fennec :)
>>>>> The Firefox product family wants push services to support the [Web Push
>>>>> HTML5 spec](https://developer.mozilla.org/en-US/docs/Web/API/Push_API).
>>>>> This is a big part of the Progressive Web Apps ini

Re: [guardian-dev] why Firefox needs GCM

[Hans-Christoph Steiner]

There is one piece of push services that only big companies can offer,
because only they can get the big telecoms to work with them.  Big
telecoms use "Carrier Grade NAT" throughout their networks.  NAT means
routers have to keep a table of the mappings between the real IP and
each client.  That table needs to be garbage collected so it does just
grow endlessly.

When a TCP connection is open while a device drops off the network or
switches to wifi, then the NAT router can't know that the TCP is no
longer valid.  So they just have a timeout, they kill all old, inactive
TCP connections.  They might do that quite aggresively.

Apple and Google then negotiate a deal to give special handling to the
TCP connection of their push services.

Now, looking back, I've heard this from a number of people but I have
never seen data on what this actually looks like.  So maybe this is just
conjecture that has never really gone away.  It would be nice to have
some real data on this.

.hc

zoki:
> It's not so easy to just open a websocket and forget.
> 
> You are loosing internet connection on a mobile device a lot of time and so
> you have to have a good logic behind to detect when your websocket is dead
> (pinging) and smart reconnecting logic.
> 
> And if that's not enough you have a problem with background execution
> (restriction) and with every new version of Android with keeping wakelocks.
> Device will go to sleep and traffic bypasses you.
> 
> Have gone through that path and it was pain :)
> 
> On Thu, Dec 14, 2017, 14:29 Nathan of Guardian <nat...@guardianproject.info>
> wrote:
> 
>> Yeah, but this perception always irks me:
>>
>> "Firefox for Desktop runs its own custom push service called `autopush`
>> that keeps long-lived Web Sockets open.  As you surely know, that's not
>> viable on a phone"
>>
>> Holding open a socket that has no data traversing it consumes almost no
>> power. GSM is essentially doing this themselves, how else does it work
>> on a wifi only device like a tablet?
>>
>> Perhaps a patch could be written for Fennec/Firefox to use the autopush
>> desktop service?
>>
>>
>> On 12/14/2017 03:39 AM, Hans-Christoph Steiner wrote:
>>>
>>> Finally, an answer to why Firefox needs GCM push services:
>>>
>> https://forum.f-droid.org/t/making-it-easier-for-f-droid-to-package-mozilla-firefox/1649/13
>>>
>>>
>>>  Forwarded Message 
>>> Subject: [F-Droid Forum] [Apps] Making it easier for F-Droid to package
>>> Mozilla Firefox
>>> Date: Tue, 05 Dec 2017 18:33:53 +
>>> From: Nick Alexander <fo...@f-droid.org>
>>>
>>> [quote="hans, post:12, topic:1649, full:true"]
>>> @nalexander about Google Play Services, what is the push stuff used for?
>>>  I never understand why Firefox needed its own push services.  But I do
>>> understand why push requires GCM on Android.
>>> [/quote]
>>>
>>> This I can answer, 'cuz I built most of this integration for Fennec :)
>>> The Firefox product family wants push services to support the [Web Push
>>> HTML5 spec](https://developer.mozilla.org/en-US/docs/Web/API/Push_API).
>>> This is a big part of the Progressive Web Apps initiative that aims to
>>> make developing rich App experiences possible using the Web Platform.
>>> Firefox for Desktop runs its own custom push service called `autopush`
>>> that keeps long-lived Web Sockets open.  As you surely know, that's not
>>> viable on a phone -- the OS is best positioned to do that work,
>>> potentially using side-channels from existing (carrier) channels.
>>> Therefore, Firefox for Android uses an `autopush` bridge to Google Cloud
>>> Messaging (and eventually will have to migrate to Firebase Cloud
>>> Messaging), and Firefox for iOS uses an `autopush` bridge to Apple Push
>>> Notification Service.
>>>
>>>
>>> ___
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>
>> ___
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] sanitizing PNGs

[Hans-Christoph Steiner]

That's awesome!  Feeling inspired to also strip JPEGs? :-)  I think
they're easier.  There is jhead, exiftool, and ObscuraCam's JNI code for
examples.  Can we use this under the GPLv3?

.hc

Michael Rogers:
> Hi Hans-Christoph,
> 
> I hacked this together based on the PNG specification, which
> distinguishes between ancillary chunks that can be removed without
> affecting the image data, and critical chunks that can't. It's been
> tested on exactly two PNGs so far. :-)
> 
> http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html
> 
> Cheers,
> Michael
> 
> On 12/12/17 16:25, Hans-Christoph Steiner wrote:
>>
>> pyexiftool is just a wrapper for exiftool.  exiftool looks great, but
>> for my use case, I only need to strip all metadata.  It would be much
>> easier if that was in pure Python and pure Java.  perl is a no go on
>> Android.
>>
>> It was dead simple to strip EXIF from JPEG in Python:
>>
>> from pil import Image
>> with open(inpath) as fp:
>> in_image = Image.open(fp)
>> data = list(in_image.getdata())
>> out_image = Image.new(in_image.mode, in_image.size)
>> out_image.putdata(data)
>> out_image.save(outpath)
>>
>> But that broke some PNGs, and the rest were larger in size.
>>
>> .hc
>>
>> Rick Valenzuela:
>>> oh, you may already know this, but the previous code keeps a copy of the
>>> file and metadata. if you want it gone with no copies, you have to add a
>>> switch to overwrite, e.g.:
>>>
>>> ```
>>> with exiftool.ExifTool() as et:
>>> et.execute(b'-all=', b'-overwrite_original', b'some.png')
>>> ```
>>>
>>> On 12/12/2017 23:45, Rick Valenzuela wrote:
>>>> heh, nice --  I just found this:
>>>>
>>>> https://github.com/smarnach/pyexiftool
>>>>
>>>> Tried it out and it worked great:
>>>> ```
>>>> with exiftool.ExifTool() as et:
>>>>  et.execute(b'-all=', b'some.png')
>>>> ```
>>>>
>>>> On 12/12/2017 19:53, Hans-Christoph Steiner wrote:
>>>>>
>>>>> Ah, cool, I thought exiftool only worked with JPEGs.  It seems to work
>>>>> with just about every image format.  Now the open question is how to
>>>>> strip all PNG metadata with Python and Java.
>>>>>
>>>>> .hc
>>>>>
>>>>> Rick Valenzuela:
>>>>>> does exiftool do what you need?
>>>>>>
>>>>>> `exiftool -all= `
>>>>>>
>>>>>> On 11/12/2017 17:57, Hans-Christoph Steiner wrote:
>>>>>>>
>>>>>>> Anyone know any tools for sanitizing PNGs without touching the
>>>>>>> compressed image data?  With JPEG it is easy to strip out EXIF with
>>>>>>> python-pil or many other tools. I haven't found a simple, clean approach
>>>>>>> in Python for PNGs.
>>>>>>>
>>>>>>> .hc
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] sanitizing PNGs

[Hans-Christoph Steiner]

Ah, cool, I thought exiftool only worked with JPEGs.  It seems to work
with just about every image format.  Now the open question is how to
strip all PNG metadata with Python and Java.

.hc

Rick Valenzuela:
> does exiftool do what you need?
> 
> `exiftool -all= `
> 
> On 11/12/2017 17:57, Hans-Christoph Steiner wrote:
>>
>> Anyone know any tools for sanitizing PNGs without touching the
>> compressed image data?  With JPEG it is easy to strip out EXIF with
>> python-pil or many other tools. I haven't found a simple, clean approach
>> in Python for PNGs.
>>
>> .hc
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] sanitizing PNGs

[Hans-Christoph Steiner]

Anyone know any tools for sanitizing PNGs without touching the
compressed image data?  With JPEG it is easy to strip out EXIF with
python-pil or many other tools. I haven't found a simple, clean approach
in Python for PNGs.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Where to locate GPG signature files for Direct APK downloads?

[Hans-Christoph Steiner]

Nathan of Guardian:
> 
> 
> On 11/13/2017 10:50 AM, Paul Schaub wrote:
>> Hi!
>>
>>
>> Am 13.11.2017 um 16:34 schrieb Nathan of Guardian:
>>>
>>> Of course, that is why we also offer our F-Droid repo, which has
>>> built-in signing by the repo build process itself:
>>> https://guardianproject.info/fdroid/
>>
>> The repo is still lacking the latest Orbot releases :(
> 
> I know. There is a human+technical workflow issue we are resolving with
> updating our F-Droid repos. Nothing to be alarmed about, and will keep
> you apprised.

All the Orbot releases on https://guardianproject.info/releases are
included in our F-Droid repo.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Syria Store - Android app store for Syria

[Hans-Christoph Steiner]

The main 3G providers in Syria, SyriaTel and MTN, are behind a new
Andrid app store that just launched:
https://www.syriastore.sy/

Interesting to see them using real HTTPS from the beginning.
http://cafebazaar.ir didn't offer HTTPS for like 2+ years.

I guess its a small effort, since there are few apps, and they are all
listed as coming from "Rand Sy".

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Ticket Proceeds from the OnePlus 5T Launch Event will benefit F-Droid

[Hans-Christoph Steiner]

Anyone know anything about this:

https://www.xda-developers.com/oneplus-5t-launch-event-ticket-proceeds-f-droid/

The OnePlus 5T was officially unveiled today at an event in Brooklyn,
New York. It offers a 6.01″ 18:9 Samsung-made OLED display along with
top-tier hardware specifications including the Qualcomm Snapdragon 835
SoC and up to 8GBs of RAM and 128GBs of internal storage. Fans of
OnePlus had the opportunity to see the unveiling live in person,
provided they were willing to pay $40 for a ticket. Those who attended
received a swag bag with lots of goodies inside. It’s rare for device
unveiling events to be open to the public, and it’s also rare to see
entry fees at these events. While unusual, the entry fee not only nets
you a swag bag and a $40 off coupon for the OnePlus 5T, but it also goes
to a good cause: funding F-Droid.

I haven't heard a thing about this.  I guess they like the new UI!

.hc


-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] No more “Root” features in Orbot… use Orfox & VPN instead!

[Hans-Christoph Steiner]

I think the situation has improved, but I'm not sure all the issues are
solved.

.hc

ban...@openmailbox.org:
> Hi I was wondering if the traffic leak problems that were documented when the 
> VPN feature was first introduced have been worked around?
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Security, Privacy Focused Librem 5 Linux Smartphone Successfully Crowdfunded

[Hans-Christoph Steiner]

This is exciting! There goals with the Librem5 hardware give all that we have 
been asking for since the beginning of Guardian Project:

http://rss.slashdot.org/~r/Slashdot/slashdot/~3/RQDyAn5RnYQ/security-privacy-focused-librem-5-linux-smartphone-successfully-crowdfunded___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] jmp.chat - SMS for XMPP (Zom/ChatSecure/Conversations/etc)

[Hans-Christoph Steiner]

Now you can have a real US/Canada phone number with your favorite
XMPP/Jabber client:

"JMP gives you a real phone number for sending picture and text messages
right from a Jabber account."

https://jmp.chat/

.hc
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] bad new bluetooth

[Hans-Christoph Steiner]

There's a new, bad bluetooth which could be bad for Viento efforts:

https://www.theverge.com/2017/9/12/16294904/bluetooth-hack-exploit-android-linux-blueborne

It also affects Bluetooth that is not discoverable, so it might mean the
only defence is turning off Bluetooth...

.hc
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] Mozilla Wireless Challenge

[Hans-Christoph Steiner]

Competition for wireless internet access targeted for minimal requirements:

https://wirelesschallenge.mozilla.org

Seems like we could submit Viento work.

.hc___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] ask Google to allow "Unknown Sources" on ChromeOS

[Hans-Christoph Steiner]

Kevin Steen:
> On 01/09/17 14:00, Hans-Christoph Steiner wrote:
>>
>> ChromeOS (the OS for Chromebooks) now has a complete Android runtime.
>> There are also persistent rumors that Google is merging ChromeOS and
>> AndroidOS into a single system.  The scary thing is that ChromeOS's
>> Android runtime does not allow users to install apps outside of Google Play.
>>
>> "Unknown Sources" is essential to a lot of the things that we do:
>>
>> * nearby app sharing like F-Droid, Zapya, Share-It, etc.
>> * alternative app stores like F-Droid and all those companies
>> * easy testing via direct APK install, Hockeyapp, etc.
>> * self-updating apps like Zom, Signal, etc.
>>
>> Anyone with a google account and an interest in keeping ChromeOS as open
>> as Android, please star this issue:
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=761329
>>
>> .hc
>>
> 
> I think Google is already well into using its monopoly to strangle out
> competitors and they're not going to reverse on that. Things like Doze
> mode and having to use Google Cloud Messaging to get any kind of
> usability are only marketed as benefiting users - the main beneficiary
> is Google. Non-Google apps are being pushed into second-class citizen
> status by making them appear unreliable.
> 
> What I don't understand is why the alternate ROM suppliers don't seem to
> want to fix these shortcomings, either. I stand to be corrected, but I
> don't think CyanogenMod ever got around to providing the Ad-hoc Wifi API
> which Google refuses to provide, either.
> 
> I think if we want to create freedom-preserving apps, we're going to
> have to encourage alternate ROMS and tell people to only buy phones
> which can be freed from Google's control. Then we still have to tackle
> the control from the baseband processor...

Google does have control, but that does not mean we do not have some
leverage.

The lockdown of GCM and doze mode is indeed a threat.

The reason why ROM devs do not add features like adhoc wifi is that it
requires a lot of testing and integration work.  Few people like to do
that kind of work in their free time, so for that to happen, people have
to get paid.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] ask Google to allow "Unknown Sources" on ChromeOS

[Hans-Christoph Steiner]

Mark Murphy:
> On Fri, Sep 1, 2017, at 09:00, Hans-Christoph Steiner wrote:
>> Anyone with a google account and an interest in keeping ChromeOS as open
>> as Android, please star this issue:
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=761329
> 
> In that issue, you state:
> 
>> At the very least, make it available in "Developer options" or via networked 
>> ADB.
> 
> However, neither "Developer options" nor networked adb are available
> unless the Chrome OS device is in developer mode (which, as you point
> out, is impractical for non-developers).
> 
> What you want is for "Unknown sources" to be available in general, at
> least in the Android 8.0 form (per-installer configuration).

Yup, Android 8.0 Unknown Sources would be the best, I think.  Those
other options would be better than nothing.

.hc



-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] ask Google to allow "Unknown Sources" on ChromeOS

[Hans-Christoph Steiner]

ChromeOS (the OS for Chromebooks) now has a complete Android runtime.
There are also persistent rumors that Google is merging ChromeOS and
AndroidOS into a single system.  The scary thing is that ChromeOS's
Android runtime does not allow users to install apps outside of Google Play.

"Unknown Sources" is essential to a lot of the things that we do:

* nearby app sharing like F-Droid, Zapya, Share-It, etc.
* alternative app stores like F-Droid and all those companies
* easy testing via direct APK install, Hockeyapp, etc.
* self-updating apps like Zom, Signal, etc.

Anyone with a google account and an interest in keeping ChromeOS as open
as Android, please star this issue:

https://bugs.chromium.org/p/chromium/issues/detail?id=761329

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Netcipher Usage of TorServiceUtils

[Hans-Christoph Steiner]

Hey Dominik,

It would be great to have you using NetCipher!  Those shell commands are
used on older platforms to detect whether Tor is running. I haven't
looked at them in a while, maybe Nathan can comment more.  If we can get
rid of them entirely and still support android-10, then that would be
the ideal outcome.

Sorry for the slow response, I was on vacation.

.hc

Dominik Schuermann:
> Hi,
> 
> In OpenKeychain we currently use a copied and modified version of
> Netcipher classes at
> https://github.com/open-keychain/open-keychain/tree/master/OpenKeychain/src/main/java/org/sufficientlysecure/keychain/network/orbot
> 
> I would use Netcipher as a dependency, but I don't like
> https://github.com/guardianproject/NetCipher/blob/master/libnetcipher/src/info/guardianproject/netcipher/proxy/TorServiceUtils.java
> 
> Are there plans to remove this class? It uses shell commands and has
> references to "Superuser.apk" and "/system/bin/su".
> 
> Finding out if Orbot runs or not should now also works using broadcast
> intents.
> 
> Cheers
> Dominik
> 
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Orbot in the GP f-droid repo is outdated

[Hans-Christoph Steiner]

The version of Orbot in the F-Droid repo has always been the
conservative stable release.  It will be getting an scheduled update
within 2 weeks.

.hc

oio...@openmailbox.org:
> Hello Devs and other subscribers.
> 
> Is there any plans to update Orbot in the Guardian Project's f-droid repo?
> 
> Looking at the google Play store it was last updated Jun 9 2017 but the
> f-droid repo it is nearly a year old with a release date of July 11 2016.
> 
> Oi
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] asking Google to open source the Play Services Android libraries

[Hans-Christoph Steiner]

Nothing specific.  I've just heard rumors that they are thinking about
it.  Lobbying Google to do this is still helpful!

.hc

Paul Schaub:
> Any news on this topic?
> 
> 
> Am 13.03.2017 um 15:37 schrieb Ted P. Samuel:
>>
>> Thanks!  Just be sure to make it clear that we are asking just for the
>> Play Services jars that are included in Android apps!
>>
>>
>> I pretty much just quoted you (sorry, no direct attribution, due to
>> likelihood of TLDR ):
>>
>>> Many folks would appreciate if you all would open-source (only) the
>> GCM jars that are distributed as part of the
>> google_m2repository distributed as part of Android Studio. Details @
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1346761 via
>> https://lists.mayfirst.org/pipermail/guardian-dev/2017-March/005200.html
>> . Thanks very much! 爛落酪
>>
>> -- 
>>
>> https://zhjf9h10ji3.ting.com/
>>
>>
>>
>> ___
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 
> 
> 
> 
> ___
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] announcing new libraries: F-Droid Update Channels

[Hans-Christoph Steiner]

In order to complete the F-Droid distribution ecosystem, we are
introducing "F-Droid Update Channels".  It is a suite of libraries for
making your that your app can always find updates, no matter where
someone got it from.

https://gitlab.com/fdroid/update-channels/

In many parts of the world, it is very common to get Android APKs
outside of the app stores where the developers upload them.

* third party app stores scrape other app stores for APKs
* APKs are bluetoothed, directly, downloaded, etc
* users share APKs via services like Aptoide

In order to ensure that your app always can find updates, we are
introducing two specific libraries:


"Get F-droid" aka org.fdroid.getfdroid

Checks whether F-Droid is installed.  If not, it will help the user to
download and install F-Droid.  F-Droid then provides the update channel.


"App Updater" aka org.fdroid.appupdater

Keeps the app current by checking the hard-coded app repository set up
by the developer.  This is similar to the popular "App Updater" library,
but is secure do to the F-Droid signed metadata.  The fdroidserver tools
handle the creation and maintenance of the app repository.


Both of these libraries also check whether Google Play is installed, if
so, will disable itself.  This allows apps to include this library in
APKs that are uploaded to Google Play since it will not violate the
Google Play Terms of Service.

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Google's new App Signing service

[Hans-Christoph Steiner]

That's a nice feature indeed.  I'm really afraid they're just going to
remove it entirely.  ChromeOS doesn't have that option, for example.
You have to put the whole device into developer mode.

.hc

Nathan of Guardian:
> That said, at Google IO, I think in the security talk, they made a big
> deal to point out the evolution of "Unknown Sources" to the ability to
> approve it for just one app, enable to support third-party app stores. 
> 
> On Tue, May 23, 2017, at 08:55 AM, Hans-Christoph Steiner wrote:
>>
>> I think the more practical, less paranoid read of this move is Google
>> trying to take control over more of the Android ecosystem.  If they can
>> get app developers to let Google to the whole release process, that will
>> make it harder to also release the app on other app stores.
>>
>> .hc
>>
>> Elmor:
>>> This is not only happening on mobiles. Since about one year, your add-ons 
>>> on Opera and Firefox are "verified". If developers do not let their add-on 
>>> veriefy, they are suspended.
>>>
>>> What also poped into my eyes was point "3. Permanent Enrolement". If you 
>>> have a well going app and the name is in all ears and mind, you will lose 
>>> that name should you decide to get out of the GPAS.
>>>
>>> If Michael's and Nathan's fears - I do share them - are true, then apps can 
>>> only be securely downloaded and installed from developers own website.
>>>
>>> Tricky move.
>>>
>>> elm-
>>>
>>>
>>>
>>> On May 19, 2017 3:12:04 PM GMT+01:00, Nathan of Guardian 
>>> <nat...@guardianproject.info> wrote:
>>>> On Fri, May 19, 2017, at 07:29 AM, Michael Rogers wrote:
>>>>> Paranoid people might suspect that this simultaneous move by Apple
>>>> and
>>>>> Google is the result of political pressure to provide some means of
>>>>> adding/removing functionality, such as end-to-end encryption.
>>>>
>>>> You read my mind.
>>>>
>>>> +n
>>>> ___
>>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>>
>>
>> -- 
>> PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
>> https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
> 
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Google's new App Signing service

[Hans-Christoph Steiner]

I think the more practical, less paranoid read of this move is Google
trying to take control over more of the Android ecosystem.  If they can
get app developers to let Google to the whole release process, that will
make it harder to also release the app on other app stores.

.hc

Elmor:
> This is not only happening on mobiles. Since about one year, your add-ons on 
> Opera and Firefox are "verified". If developers do not let their add-on 
> veriefy, they are suspended.
> 
> What also poped into my eyes was point "3. Permanent Enrolement". If you have 
> a well going app and the name is in all ears and mind, you will lose that 
> name should you decide to get out of the GPAS.
> 
> If Michael's and Nathan's fears - I do share them - are true, then apps can 
> only be securely downloaded and installed from developers own website.
> 
> Tricky move.
> 
> elm-
> 
> 
> 
> On May 19, 2017 3:12:04 PM GMT+01:00, Nathan of Guardian 
>  wrote:
>> On Fri, May 19, 2017, at 07:29 AM, Michael Rogers wrote:
>>> Paranoid people might suspect that this simultaneous move by Apple
>> and
>>> Google is the result of political pressure to provide some means of
>>> adding/removing functionality, such as end-to-end encryption.
>>
>> You read my mind.
>>
>> +n
>> ___
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Google's new App Signing service

[Hans-Christoph Steiner]

With iOS, you need to use Apple tools to decrypt your official app
binary, so there is no way to verify that Apple isn't inserting
anything.  With Android, we'll still be able to compare APKs.  So if you
submit an app that was reproducibly built, then you can compare the
Google APK to your own and see the differences.

That would not protect users from targeted malware, like what the FBI
wanted to do in FBI v. Apple.  Google can now join Apple in potentially
providing that as a service.

This is why in F-Droid we have put a big emphasis on treating the server
as a threat.  We want to make it as difficult as possible for a
malicious server to do targeted software delivery.  Then we're also
working to make it as easy as possible for anyone to setup automated
auditing systems like https://verification.f-droid.org.

.hc

Natanael:
> Is  there any plausible way to get them to only apply verifiable
> modifications? Such as compression using algorithms proven to preserve
> original behavior?
> 
> I'm aware that would require a ton of resources (both in development and
> computationally), but is it doable?
> 
> - Sent from my phone
> 
> Den 19 maj 2017 16:12 skrev "Nathan of Guardian" <
> nat...@guardianproject.info>:
> 
>> On Fri, May 19, 2017, at 07:29 AM, Michael Rogers wrote:
>>> Paranoid people might suspect that this simultaneous move by Apple and
>>> Google is the result of political pressure to provide some means of
>>> adding/removing functionality, such as end-to-end encryption.
>>
>> You read my mind.
>>
>> +n
>> ___
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org
>>
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Google's new App Signing service

[Hans-Christoph Steiner]

Lol, so it turns out that F-Droid was a pioneer and innovator, years
ahead of Google ;-)

Looks like a play to give Google more info on releases, since all
releases must go through them.  It would also encourage developers to
use Google as the gatekeeper for app releases.  I guess this could also
be some kind key backup.

Anyone see anything about their motivations for doing this?  I wonder
how much data they have on signing keys getting stolen and abused.

.hc

Nathan of Guardian:
> Just logged into Play and found this:
> https://support.google.com/googleplay/android-developer/answer/7384423
> 
> 
> "Google Play
> Google Play App Signing Terms of Service
> 
> Effective as of May 17th 2017
> 
> By enrolling Your application (“app”) in Google Play App Signing (GPAS)
> service, You consent to be bound by these terms, in addition to the
> existing Google Play Developer Distribution Agreement (“DDA”) and Google
> Play Developer Program Policies (collectively, the “Agreement”). If
> there is a conflict between these terms and the Agreement, these terms
> govern use of Your app in GPAS. Capitalized terms used below, but not
> defined below, have the meaning ascribed to them under the Agreement.
> 
> 1. Key Generation and Storage
> 
> 1.1. GPAS is an optional service that provides a secure means of
> handling Your app signing key.
> 
> 1.2. By enrolling Your existing app in GPAS, You agree to give Your
> existing app’s signing key to Google and to secure or delete Your
> copy(ies) of the key. For new apps, Google will generate a new app
> signing key for Your app.
> 
> 1.3. You will have the ability to download and review any APKs you
> publish that are signed by Google.
> 
> 2. Automated App Optimizations
> 
> 2.1. By enrolling Your app in GPAS, in addition to the license granted
> in 5.1 of the DDA, You grant Google a license to modify Your app APKs to
> optimize their performance, security and/or size, for the life of the
> app. The modifications, and the timing of which, will be made at
> Google’s sole discretion.
> 
> 2.2. For the avoidance of doubt, services provided in GPAS are not
> intended to change the purpose of Your app.
> 
> 3. Permanent Enrollment
> 
> 3.1. It will not be possible to retrieve Your app signing key once it is
> provided to or generated by Google.
> 
> 3.2. You can unpublish Your app and publish a new app with a new package
> name, without opting into GPAS, at any time.
> 
> 4. Optional App Optimizations
> 
> 4.1. Google may offer You app optimizations, separate from the automated
> ones referenced in Section 2, that You may choose to apply to Your apps
> enrolled in GPAS.
> 
> 4.2. You are not required to accept any of these optional app
> optimizations.
> 
> 4.3. If You choose to apply an optional app optimization, You can
> opt-out of any you choose at any time.
> 
> 5. Changes to the Agreement
> 
> 5.1. Google may make changes to these terms at any time by sending You
> reasonable notice describing the modifications made. Google also will
> post a notification on the Google Play Console describing the
> modifications made. They will become effective, and will be deemed
> accepted by You, (a) immediately for those who opt-in to GPAS after the
> notification is provided, or (b) for pre-existing GPAS users, on the
> date specified in the notice. If You do not agree with the modifications
> to the Terms, You must withdraw from GPAS, subject to Section 3, which
> will be Your sole and exclusive remedy. You agree that Your failure to
> withdraw constitutes Your agreement to the modified terms.
> 
> © Google  Privacy & Terms  Help"
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

[guardian-dev] getting useful tracking data from our F-Droid repo without leaking privacy

[Hans-Christoph Steiner]

Hey Nathan,

I'd like to try to enable some privacy-preserving tracking on the
Guardian Project F-Droid repo.  Looks like logging was turned off August
19, 2014.  What do you think about turning on the Apache logging again,
but only keeping the logs for one day?

For the F-Droid repo, there would be a cron'ed script that would take
just what was downloaded and what time.  I'm tempted to also convert the
IP address to a country, and store that.

Rounding off the time to the day seems like a nice balance of useful
info without giving away too much.  That eliminates the rich time-of-day
metadata, e.g. night, morning, lunchtime, etc.  But maybe rounding to
the week would be better since that would also eliminate info about the
weekly cycle (e.g. downloads on Friday evening are not likely to come
from an orthodox Muslim, or Saturday for an orthodox Jew; then there are
holidays, etc.).

.hc

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org

Re: [guardian-dev] Orbot as a pure VPN?

[Hans-Christoph Steiner]

I think this is a better approach for Tor on Android, given a similar
level of resources to work on it.  If we had a lot more developer and UX
time, I think we could manage it all in a single app.

We should work on getting Tor itself as a library, and then make that
library detect whether Tor is already provided from another trusted app
(e.g. Orbot, Orfox).  When Tor is already provided, then the library
should disable the included Tor and route traffic to the other trusted
Tor app.

.hc

Nathan of Guardian:
> There was a lot of "we need to make tor easier" discussions at the Tor
> dev meeting, in particular thinking about mobile first/only type users.
> One thing I realized is that Orbot today is neither a VPN or a browser,
> and that confuses many users, since it doesn't fit into a neat category.
> For many places in the world, there is a need for a trustworthy, free,
> open-source "unblocking" service. We had reports from trainers in South
> America who said that the current user experience of Orbot was confusing
> for novice users who just wanted to access sites or use apps that were
> blocked.
> 
> So, for my hackathon time for tor dev, I created a new variation on the
> Orbot user experience, called OrbVPN or Orbot VPN. It is a pure VPN
> version of the app with a single "connect" button, that lets the user
> choose which apps to use with Tor, through a grid of app icons. It only
> shows app that have the "internet" permission requested, and that have
> proper names (i.e. not system services). There is no "tor everything"
> option - the user must choose the specific apps they want to "unblock":
> 
> You can find the APK and source here:
> https://github.com/n8fr8/orbotconnect/releases/tag/0.0.1-prototype-1
> t
> The app is also quite small, less than 5 MB. This is because it doesn't
> include any of the root/transproxy code, the polipo http proxy, or the
> obfs4 bridge client. Most of that is still Tor itself (around 3MB), but
> we had additional discussions at the dev meeting about working to make a
> stripped down "client only" build of Tor, that wouldn't include any of
> the more server-oriented functionality.
> 
> It also requires Android 5+, since that is where the VPN API works the
> best, and allows for easy white-listing of apps without hijinks.
> 
> Anyhow, just food for thought, and potentially a future direction. We
> also want to move to having Tor and other native dependencies be
> available as official standalone gradle libs/AARs, to make the
> experimentation, creation and maintenance of these different kinds of
> user experiences around Tor much easier. 
> 
> +n
> 

-- 
PGP fingerprint: EE66 20C7 136B 0D2C 456C  0A4D E9E2 8DEA 00AA 5556
https://pgp.mit.edu/pks/lookup?op=vindex=0xE9E28DEA00AA5556
___
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
To unsubscribe, email:  guardian-dev-unsubscr...@lists.mayfirst.org