Decryption support in Briefcase

ODKers,

In order for field staff to be able to download and decrypt data using
Briefcase, they typically have to first install the* Java Cryptography
Extension (JCE) Unlimited Strength Jurisdiction Policy Files* in order to
upgrade their JREs to support the key size used by ODK. If they don't, they
are treated to an "illegal key size" exception upon attempting decryption.
This has been a support headache and I am trying to devise a longer-term
strategy that works around this problem.

One option would be to build a custom Briefcase installer that installs the
necessary JCE files. However, my understanding is that this installer would
be subject to U.S. export restrictions. Thus, I am unsure of the legality
of broadly distributing such an installer.

Another option would be to default ODK encryption to 128-bit and allow an
option for stronger encryption. Perhaps some kind of option along these
lines already exists? Ideally, you would be able to use stronger encryption
in those contexts for which it is legal, and weaker in others.

Does anybody have any thoughts on this? One way or another I'd like to make
the process of deploying encrypted forms easier, and this JRE/JCE issue is
a real hang-up. I can't imagine that I'm alone here.

Thanks,

Chris

Hi Chris,
I ran into a small problem decrypting data in briefcase. I installed
the JCE 7 as described below, and successfully decrypted a trial entry
from the form I was using. However, I am now getting the error:
"Error decrypting submission .... Cause:
org.opendatakit.briefcase.model.ParsingException: Missing
base64EncryptedKey element in encrypted form." I went into the
briefcase storage looked at the offending instance folder- that folder
was missing the submission.xml.enc file. I removed that particular
instance folder and had no trouble decrypting the rest of the
instances (there were around 220 total). Why would one instance be
missing the encryption file necessary to decrypt? Is it just that the
enumerator failed to save the form, the form wasn't complete, etc?
Since it was only one instance out of 220, it wasn't a big problem,
but I would like to understand the cause to prevent it from happening
in the future.
Thanks,
Allyson

··· On Aug 6, 6:29 am, Christopher Robert wrote: > ODKers, > > In order for field staff to be able to download and decrypt data using > Briefcase, they typically have to first install the* Java Cryptography > Extension (JCE) Unlimited Strength Jurisdiction Policy Files* in order to > upgrade their JREs to support the key size used by ODK. If they don't, they > are treated to an "illegal key size" exception upon attempting decryption. > This has been a support headache and I am trying to devise a longer-term > strategy that works around this problem. > > One option would be to build a custom Briefcase installer that installs the > necessary JCE files. However, my understanding is that this installer would > be subject to U.S. export restrictions. Thus, I am unsure of the legality > of broadly distributing such an installer. > > Another option would be to default ODK encryption to 128-bit and allow an > option for stronger encryption. Perhaps some kind of option along these > lines already exists? Ideally, you would be able to use stronger encryption > in those contexts for which it is legal, and weaker in others. > > Does anybody have any thoughts on this? One way or another I'd like to make > the process of deploying encrypted forms easier, and this JRE/JCE issue is > a real hang-up. I can't imagine that I'm alone here. > > Thanks, > > Chris

Also if you haven't already file an issue on our website about
changing the level of encryption. The problem is that we don't want to
make it easy enough for someone to break. However you bring up good
points so file an issue so that ODK core team discusses how we might
address this.

Waylon

··· On Sun, Aug 5, 2012 at 11:29 PM, Christopher Robert wrote: > ODKers, > > In order for field staff to be able to download and decrypt data using > Briefcase, they typically have to first install the Java Cryptography > Extension (JCE) Unlimited Strength Jurisdiction Policy Files in order to > upgrade their JREs to support the key size used by ODK. If they don't, they > are treated to an "illegal key size" exception upon attempting decryption. > This has been a support headache and I am trying to devise a longer-term > strategy that works around this problem. > > One option would be to build a custom Briefcase installer that installs the > necessary JCE files. However, my understanding is that this installer would > be subject to U.S. export restrictions. Thus, I am unsure of the legality of > broadly distributing such an installer. > > Another option would be to default ODK encryption to 128-bit and allow an > option for stronger encryption. Perhaps some kind of option along these > lines already exists? Ideally, you would be able to use stronger encryption > in those contexts for which it is legal, and weaker in others. > > Does anybody have any thoughts on this? One way or another I'd like to make > the process of deploying encrypted forms easier, and this JRE/JCE issue is a > real hang-up. I can't imagine that I'm alone here. > > Thanks, > > Chris > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en

Despite relatively valiant efforts to ease the installation of JCE
jurisdiction files on Briefcase's first run, some Windows configurations
still make automated (or semi-automated) installation difficult to
impossible. This continues to be a major headache for projects using
encryption.

We are now considering using Bouncy Castle's proprietary API to bypass JCE
entirely. Has anybody tried or considered this? Any pitfalls we should be
aware of? We would leave Collect encrypting as-is, but decryption would
shift to Bouncy Castle.

If we get this to work, we are happy to submit back to the ODK community.
This is a thorn in everybody's side, I think.

Any advice or warnings would be appreciated.

Thanks,

Chris

··· On Mon, Aug 6, 2012 at 8:29 AM, Christopher Robert wrote:

ODKers,

In order for field staff to be able to download and decrypt data using
Briefcase, they typically have to first install the* Java Cryptography
Extension (JCE) Unlimited Strength Jurisdiction Policy Files* in order to
upgrade their JREs to support the key size used by ODK. If they don't, they
are treated to an "illegal key size" exception upon attempting decryption.
This has been a support headache and I am trying to devise a longer-term
strategy that works around this problem.

One option would be to build a custom Briefcase installer that installs
the necessary JCE files. However, my understanding is that this installer
would be subject to U.S. export restrictions. Thus, I am unsure of the
legality of broadly distributing such an installer.

Another option would be to default ODK encryption to 128-bit and allow an
option for stronger encryption. Perhaps some kind of option along these
lines already exists? Ideally, you would be able to use stronger encryption
in those contexts for which it is legal, and weaker in others.

Does anybody have any thoughts on this? One way or another I'd like to
make the process of deploying encrypted forms easier, and this JRE/JCE
issue is a real hang-up. I can't imagine that I'm alone here.

Thanks,

Chris

Are you using briefcase to pull directly from the phone? If yes than
"is it just that the enumerator failed to save the form, the form
wasn't complete, etc?"

Then the answer is yes to that question as the encyption happens when
they say they are finished. As once Collect encrypts it cannot
unencrpyt the data to continue the form later.

If briefcase is getting the data from Aggregate then that shouldn't happen.

Please elaborate more on where the unencrypted solution is coming from.

Waylon

··· On Sun, Aug 19, 2012 at 6:48 AM, Allyson Barnett wrote: > Hi Chris, > I ran into a small problem decrypting data in briefcase. I installed > the JCE 7 as described below, and successfully decrypted a trial entry > from the form I was using. However, I am now getting the error: > "Error decrypting submission .... Cause: > org.opendatakit.briefcase.model.ParsingException: Missing > base64EncryptedKey element in encrypted form." I went into the > briefcase storage looked at the offending instance folder- that folder > was missing the submission.xml.enc file. I removed that particular > instance folder and had no trouble decrypting the rest of the > instances (there were around 220 total). Why would one instance be > missing the encryption file necessary to decrypt? Is it just that the > enumerator failed to save the form, the form wasn't complete, etc? > Since it was only one instance out of 220, it wasn't a big problem, > but I would like to understand the cause to prevent it from happening > in the future. > Thanks, > Allyson > > On Aug 6, 6:29 am, Christopher Robert wrote: >> ODKers, >> >> In order for field staff to be able to download and decrypt data using >> Briefcase, they typically have to first install the* Java Cryptography >> Extension (JCE) Unlimited Strength Jurisdiction Policy Files* in order to >> upgrade their JREs to support the key size used by ODK. If they don't, they >> are treated to an "illegal key size" exception upon attempting decryption. >> This has been a support headache and I am trying to devise a longer-term >> strategy that works around this problem. >> >> One option would be to build a custom Briefcase installer that installs the >> necessary JCE files. However, my understanding is that this installer would >> be subject to U.S. export restrictions. Thus, I am unsure of the legality >> of broadly distributing such an installer. >> >> Another option would be to default ODK encryption to 128-bit and allow an >> option for stronger encryption. Perhaps some kind of option along these >> lines already exists? Ideally, you would be able to use stronger encryption >> in those contexts for which it is legal, and weaker in others. >> >> Does anybody have any thoughts on this? One way or another I'd like to make >> the process of deploying encrypted forms easier, and this JRE/JCE issue is >> a real hang-up. I can't imagine that I'm alone here. >> >> Thanks, >> >> Chris > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en

Interesting; Briefcase already uses BouncyCastle.

If you get this to work without needing the JCE files, let me know. I'd be
interested in folding the changes into the main Briefcase code.

Mitch

··· On Tue, Apr 9, 2013 at 2:08 AM, Christopher Robert wrote:

Despite relatively valiant efforts to ease the installation of JCE
jurisdiction files on Briefcase's first run, some Windows configurations
still make automated (or semi-automated) installation difficult to
impossible. This continues to be a major headache for projects using
encryption.

We are now considering using Bouncy Castle's proprietary API to bypass JCE
entirely. Has anybody tried or considered this? Any pitfalls we should be
aware of? We would leave Collect encrypting as-is, but decryption would
shift to Bouncy Castle.

If we get this to work, we are happy to submit back to the ODK community.
This is a thorn in everybody's side, I think.

Any advice or warnings would be appreciated.

Thanks,

Chris

On Mon, Aug 6, 2012 at 8:29 AM, Christopher Robert <chrislrobert@gmail.com wrote:

ODKers,

In order for field staff to be able to download and decrypt data using
Briefcase, they typically have to first install the* Java Cryptography
Extension (JCE) Unlimited Strength Jurisdiction Policy Files* in order
to upgrade their JREs to support the key size used by ODK. If they don't,
they are treated to an "illegal key size" exception upon attempting
decryption. This has been a support headache and I am trying to devise a
longer-term strategy that works around this problem.

One option would be to build a custom Briefcase installer that installs
the necessary JCE files. However, my understanding is that this installer
would be subject to U.S. export restrictions. Thus, I am unsure of the
legality of broadly distributing such an installer.

Another option would be to default ODK encryption to 128-bit and allow an
option for stronger encryption. Perhaps some kind of option along these
lines already exists? Ideally, you would be able to use stronger encryption
in those contexts for which it is legal, and weaker in others.

Does anybody have any thoughts on this? One way or another I'd like to
make the process of deploying encrypted forms easier, and this JRE/JCE
issue is a real hang-up. I can't imagine that I'm alone here.

Thanks,

Chris

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

JCE enforces the jurisdiction restrictions, but the BC lightweight API
bypasses them. We'll see if we can get it to work. The trick is just
figuring out the parameters, etc.

Chris

··· On Apr 9, 2013 6:57 PM, "Mitch Sundt" wrote:

Interesting; Briefcase already uses BouncyCastle.

If you get this to work without needing the JCE files, let me know. I'd be
interested in folding the changes into the main Briefcase code.

Mitch

On Tue, Apr 9, 2013 at 2:08 AM, Christopher Robert crobert@surveycto.comwrote:

Despite relatively valiant efforts to ease the installation of JCE
jurisdiction files on Briefcase's first run, some Windows configurations
still make automated (or semi-automated) installation difficult to
impossible. This continues to be a major headache for projects using
encryption.

We are now considering using Bouncy Castle's proprietary API to bypass
JCE entirely. Has anybody tried or considered this? Any pitfalls we should
be aware of? We would leave Collect encrypting as-is, but decryption would
shift to Bouncy Castle.

If we get this to work, we are happy to submit back to the ODK community.
This is a thorn in everybody's side, I think.

Any advice or warnings would be appreciated.

Thanks,

Chris

On Mon, Aug 6, 2012 at 8:29 AM, Christopher Robert < chrislrobert@gmail.com> wrote:

ODKers,

In order for field staff to be able to download and decrypt data using
Briefcase, they typically have to first install the* Java Cryptography
Extension (JCE) Unlimited Strength Jurisdiction Policy Files* in order
to upgrade their JREs to support the key size used by ODK. If they don't,
they are treated to an "illegal key size" exception upon attempting
decryption. This has been a support headache and I am trying to devise a
longer-term strategy that works around this problem.

One option would be to build a custom Briefcase installer that installs
the necessary JCE files. However, my understanding is that this installer
would be subject to U.S. export restrictions. Thus, I am unsure of the
legality of broadly distributing such an installer.

Another option would be to default ODK encryption to 128-bit and allow
an option for stronger encryption. Perhaps some kind of option along these
lines already exists? Ideally, you would be able to use stronger encryption
in those contexts for which it is legal, and weaker in others.

Does anybody have any thoughts on this? One way or another I'd like to
make the process of deploying encrypted forms easier, and this JRE/JCE
issue is a real hang-up. I can't imagine that I'm alone here.

Thanks,

Chris

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Hello Chris, Allyson and Waylon,

this has been the closes thread similar to the issue I am facing right now
to decrypt a finalized form in odk brief case, for the record, I have JCE 6
installed in the right jre location.

Also in my xls worksheet, my submissions_url reads"
"m16ezra.appspot.com/submission" with the respective public_key column
filled with the public key.

I created a public and primary key with openSSL as described
http://opendatakit.org/help/encrypted-forms/ however I get the following
error when I use the private key created to decrypt the form:

"cause org.opendatakit.breifcase.model.CryptoException: error decrypting
base64encryptedKey cause: javax.crypto.BadPaddingException:data hash wrong
Failed! "

Any ideas what this means and how I could possible solve this.

Thanks.
Regards.
Ezra

··· On Wednesday, August 22, 2012 8:14:13 PM UTC+3, Allyson Barnett wrote: > > Thanks for your response. We are pulling data directly from devices so > that is what happened I think. I filed issue #670 > http://code.google.com/p/opendatakit/issues/detail?id=670 > > On Sunday, August 19, 2012 7:05:35 PM UTC, Waylon Brunette wrote: > > Also if you haven't already file an issue on our website about > > > > changing the level of encryption. The problem is that we don't want to > > > > make it easy enough for someone to break. However you bring up good > > > > points so file an issue so that ODK core team discusses how we might > > > > address this. > > > > > > > > Waylon > > > > > > > > On Sun, Aug 5, 2012 at 11:29 PM, Christopher Robert <chrisl...@gmail.com > wrote: > > > > > ODKers, > > > > > > > > > > In order for field staff to be able to download and decrypt data using > > > > > Briefcase, they typically have to first install the Java Cryptography > > > > > Extension (JCE) Unlimited Strength Jurisdiction Policy Files in order > to > > > > > upgrade their JREs to support the key size used by ODK. If they don't, > they > > > > > are treated to an "illegal key size" exception upon attempting > decryption. > > > > > This has been a support headache and I am trying to devise a > longer-term > > > > > strategy that works around this problem. > > > > > > > > > > One option would be to build a custom Briefcase installer that > installs the > > > > > necessary JCE files. However, my understanding is that this installer > would > > > > > be subject to U.S. export restrictions. Thus, I am unsure of the > legality of > > > > > broadly distributing such an installer. > > > > > > > > > > Another option would be to default ODK encryption to 128-bit and allow > an > > > > > option for stronger encryption. Perhaps some kind of option along these > > > > > lines already exists? Ideally, you would be able to use stronger > encryption > > > > > in those contexts for which it is legal, and weaker in others. > > > > > > > > > > Does anybody have any thoughts on this? One way or another I'd like to > make > > > > > the process of deploying encrypted forms easier, and this JRE/JCE > issue is a > > > > > real hang-up. I can't imagine that I'm alone here. > > > > > > > > > > Thanks, > > > > > > > > > > Chris > > > > > > > > > > -- > > > > > Post: opend...@googlegroups.com > > > > > Unsubscribe: opendatakit...@googlegroups.com > > > > > Options: http://groups.google.com/group/opendatakit?hl=en >

This does look technically feasible, and not too bad either.

However, I am now getting cold feet. Our current system semi-automates the
process so that users themselves agree to the Oracle license agreement and
download the strong-encryption support -- we just bring them to the right
place and then actually install the files for them, once they've downloaded
them. This has the property that users themselves agree to any
restrictions, and decide themselves about the legality of strong encryption.

By using strong encryption via the Bouncy Castle API to effectively bypass
Java jurisdiction limits, it seems like we might be inadvertently exporting
illegal technology in some cases. I don't really understand what legal
restrictions do or don't exist in which countries, but I would hate to be
doing something illegal.

Does anybody have a better sense of the legal issues?

Thanks,

Chris

··· On Tue, Apr 9, 2013 at 8:19 PM, Christopher Robert wrote:

JCE enforces the jurisdiction restrictions, but the BC lightweight API
bypasses them. We'll see if we can get it to work. The trick is just
figuring out the parameters, etc.

Chris
On Apr 9, 2013 6:57 PM, "Mitch Sundt" mitchellsundt@gmail.com wrote:

Interesting; Briefcase already uses BouncyCastle.

If you get this to work without needing the JCE files, let me know. I'd
be interested in folding the changes into the main Briefcase code.

Mitch

On Tue, Apr 9, 2013 at 2:08 AM, Christopher Robert <crobert@surveycto.com wrote:

Despite relatively valiant efforts to ease the installation of JCE
jurisdiction files on Briefcase's first run, some Windows configurations
still make automated (or semi-automated) installation difficult to
impossible. This continues to be a major headache for projects using
encryption.

We are now considering using Bouncy Castle's proprietary API to bypass
JCE entirely. Has anybody tried or considered this? Any pitfalls we should
be aware of? We would leave Collect encrypting as-is, but decryption would
shift to Bouncy Castle.

If we get this to work, we are happy to submit back to the ODK
community. This is a thorn in everybody's side, I think.

Any advice or warnings would be appreciated.

Thanks,

Chris

On Mon, Aug 6, 2012 at 8:29 AM, Christopher Robert < chrislrobert@gmail.com> wrote:

ODKers,

In order for field staff to be able to download and decrypt data using
Briefcase, they typically have to first install the* Java Cryptography
Extension (JCE) Unlimited Strength Jurisdiction Policy Files* in order
to upgrade their JREs to support the key size used by ODK. If they don't,
they are treated to an "illegal key size" exception upon attempting
decryption. This has been a support headache and I am trying to devise a
longer-term strategy that works around this problem.

One option would be to build a custom Briefcase installer that installs
the necessary JCE files. However, my understanding is that this installer
would be subject to U.S. export restrictions. Thus, I am unsure of the
legality of broadly distributing such an installer.

Another option would be to default ODK encryption to 128-bit and allow
an option for stronger encryption. Perhaps some kind of option along these
lines already exists? Ideally, you would be able to use stronger encryption
in those contexts for which it is legal, and weaker in others.

Does anybody have any thoughts on this? One way or another I'd like to
make the process of deploying encrypted forms easier, and this JRE/JCE
issue is a real hang-up. I can't imagine that I'm alone here.

Thanks,

Chris

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ezra,

You might receive that error if anything changed between encryption time
and decryption time. So, for example, we've seen it when the submission URL
changed slightly, but there was still some old form data that had been
encrypted with the older submission URL. Likewise, if you changed the key
that you were using, but still had some old form data, you would run into
trouble.

I would suggest the following:

  1. Delete the form completely from the server.

  2. Delete the blank form from your device, as well as any filled-out forms.

  3. Locate your Briefcase storage directory, and, within its "forms"
    subdirectory, fully delete the subdirectory for your form.

  4. Update your form definition to have an "https://" at the beginning of
    your submission URL. Confirm also that the column header is
    "submission_url" (not "submissions_url").

  5. Upload your form anew and try everything again. With any luck, it will
    work just fine.

(If you want to skip steps 1-3, you can also just change your form's formid
and title, and that should avoid any issues with old data from earlier
attempts.)

Best,

Chris

··· On Tue, May 7, 2013 at 8:15 AM, Rwakazooba Ezra Aliija <rwakazooba@gmail.com wrote:

Hello Chris, Allyson and Waylon,

this has been the closes thread similar to the issue I am facing right now
to decrypt a finalized form in odk brief case, for the record, I have JCE 6
installed in the right jre location.

Also in my xls worksheet, my submissions_url reads" "
m16ezra.appspot.com/submission" with the respective public_key column
filled with the public key.

I created a public and primary key with openSSL as described
http://opendatakit.org/help/encrypted-forms/ however I get the following
error when I use the private key created to decrypt the form:

"cause org.opendatakit.breifcase.model.CryptoException: error decrypting
base64encryptedKey cause: javax.crypto.BadPaddingException:data hash wrong
Failed! "

Any ideas what this means and how I could possible solve this.

Thanks.
Regards.
Ezra

On Wednesday, August 22, 2012 8:14:13 PM UTC+3, Allyson Barnett wrote:

Thanks for your response. We are pulling data directly from devices so
that is what happened I think. I filed issue #670
http://code.google.com/p/**opendatakit/issues/detail?id=**670http://code.google.com/p/opendatakit/issues/detail?id=670

On Sunday, August 19, 2012 7:05:35 PM UTC, Waylon Brunette wrote:

Also if you haven't already file an issue on our website about

changing the level of encryption. The problem is that we don't want to

make it easy enough for someone to break. However you bring up good

points so file an issue so that ODK core team discusses how we might

address this.

Waylon

On Sun, Aug 5, 2012 at 11:29 PM, Christopher Robert chrisl...@gmail.com wrote:

ODKers,

In order for field staff to be able to download and decrypt data using

Briefcase, they typically have to first install the Java Cryptography

Extension (JCE) Unlimited Strength Jurisdiction Policy Files in order
to

upgrade their JREs to support the key size used by ODK. If they
don't, they

are treated to an "illegal key size" exception upon attempting
decryption.

This has been a support headache and I am trying to devise a
longer-term

strategy that works around this problem.

One option would be to build a custom Briefcase installer that
installs the

necessary JCE files. However, my understanding is that this installer
would

be subject to U.S. export restrictions. Thus, I am unsure of the
legality of

broadly distributing such an installer.

Another option would be to default ODK encryption to 128-bit and
allow an

option for stronger encryption. Perhaps some kind of option along
these

lines already exists? Ideally, you would be able to use stronger
encryption

in those contexts for which it is legal, and weaker in others.

Does anybody have any thoughts on this? One way or another I'd like
to make

the process of deploying encrypted forms easier, and this JRE/JCE
issue is a

real hang-up. I can't imagine that I'm alone here.

Thanks,

Chris

--

Post: opend...@googlegroups.com

Unsubscribe: opendatakit...@**googlegroups.com

Options: http://groups.google.com/**group/opendatakit?hl=enhttp://groups.google.com/group/opendatakit?hl=en

--
--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.