bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Thomas Fitzsimmons-2
Hi,

Some email services seem to be moving toward requiring MUAs to support
OAuth 2.0, one reason being that they would like MUAs to do two factor
authentication.  It would be nice to have this capability in Gnus's
nnimap.

The Gnus manual makes no mention of OAuth 2.0, I can't find any
suggested configurations online, and there's nothing mentioned in
debbugs about this.

Is support for OAuth 2.0 -- perhaps via oauth2.el available in GNU ELPA
-- something that Gnus could eventually implement?  If so, I guess this
bug report could be where the idea is discussed.

Thanks,
Thomas



Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Lars Ingebrigtsen
Thomas Fitzsimmons <[hidden email]> writes:

> Is support for OAuth 2.0 -- perhaps via oauth2.el available in GNU ELPA
> -- something that Gnus could eventually implement?  If so, I guess this
> bug report could be where the idea is discussed.

I don't think there's any way to ship Emacs with built-in oauth2 support
for doing auth with Gmail -- it requires distributions with API secrets
and stuff, and there's no secrets in the Emacs distribution.

Or is there a way to do that now?  I haven't been paying attention the
last few months.  I remember Thunderbird including some credentials in
the source code and saying, jokily, "remember, these are secret".
Somebody would have to register the Emacs "app" with Google, and for
Emacs, that would have to be the FSF, right?  And I don't see that
happening ever, ideologically.

But somebody could definitely write a package and put that on MELPA, and
do the registration, I think?  (With the same joke, of course.)

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Noam Postavsky
On Tue, 19 May 2020 at 08:47, Lars Ingebrigtsen <[hidden email]> wrote:

> > Is support for OAuth 2.0 -- perhaps via oauth2.el available in GNU ELPA
> > -- something that Gnus could eventually implement?  If so, I guess this
> > bug report could be where the idea is discussed.
>
> I don't think there's any way to ship Emacs with built-in oauth2 support
> for doing auth with Gmail -- it requires distributions with API secrets

There is something called xoauth2, is that related? Someone posted a
package for it, but the docs are a bit thin...

https://github.com/ccrusius/auth-source-xoauth2



Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Lars Ingebrigtsen
Noam Postavsky <[hidden email]> writes:

> There is something called xoauth2, is that related? Someone posted a
> package for it, but the docs are a bit thin...
>
> https://github.com/ccrusius/auth-source-xoauth2

Below are the instructions for end-user usage.  I think you can sum that
up as "er, no".  :-/

   1. Go to the developer console,  
   https://console.developers.google.com/project 
   2. Create a new project (if necessary), and select it once created.  
   3. Select \"APIs & Services\" from the navigation menu.  
   4. Select \"Credentials\".  
   5. Create new credentials of type \"OAuth Client ID\".  
   6. Choose application type \"Other\".  
   7. Choose a name for the client.  
     
   This should get you all the values but for the refresh token. For that one:  
     
   1. Clone the https://github.com/google/gmail-oauth2-tools repository  
   2. Execute the following command in the cloned repository:  
     
   python2.7 python/oauth2.py  
   --generate_oauth2_token \  
   --client_id=<client id from previous steps> \  
   --client_secret=<client secret from previous steps>  
     
   You should now have all the required values (the :token-url value should  
   be \"https://accounts.google.com/o/oauth2/token\").")  


--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Thomas Fitzsimmons-2
In reply to this post by Lars Ingebrigtsen
Lars Ingebrigtsen <[hidden email]> writes:

> Thomas Fitzsimmons <[hidden email]> writes:
>
>> Is support for OAuth 2.0 -- perhaps via oauth2.el available in GNU ELPA
>> -- something that Gnus could eventually implement?  If so, I guess this
>> bug report could be where the idea is discussed.
>
> I don't think there's any way to ship Emacs with built-in oauth2 support
> for doing auth with Gmail -- it requires distributions with API secrets
> and stuff, and there's no secrets in the Emacs distribution.
>
> Or is there a way to do that now?  I haven't been paying attention the
> last few months.  I remember Thunderbird including some credentials in
> the source code and saying, jokily, "remember, these are secret".
> Somebody would have to register the Emacs "app" with Google, and for
> Emacs, that would have to be the FSF, right?  And I don't see that
> happening ever, ideologically.

I suppose it depends on what Google wants during the registration
process; I've never tried this registration process before so I don't
know what's involved.  Maybe someone from the FSF could research this?
Maybe a solution could be found for Free Software like Emacs.
Thunderbird is mentioned as a not-less-secure-app, so they seem to have
solved this problem to Thunderbird/Google's satisfaction.

According to communications I've received for my Google "G Suite" email
service, Google plans to change these "less secure app" policies such
that next year they won't allow Gnus to connect using username/password
authentication like it does today.

> But somebody could definitely write a package and put that on MELPA, and
> do the registration, I think?  (With the same joke, of course.)

OK, maybe Google could relax the secrecy requirement for Emacs though,
since I'd hope they'd be sufficiently Free-Software-friendly to work
something out.  I assume, given what Thunderbird is doing, that the
secrecy requirement isn't something fundamental to OAuth 2.0's security.

Thomas



Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Richard Stallman
In reply to this post by Thomas Fitzsimmons-2
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Some email services seem to be moving toward requiring MUAs to support
  > OAuth 2.0, one reason being that they would like MUAs to do two factor
  > authentication.  It would be nice to have this capability in Gnus's
  > nnimap.

This may raise some moral issues -- depending on what practical
requirements there are.  Would you like to explain to me how the
two-factor authentication works in practice, and what the user needs
to have?

For instance, can the user do this using nothing but Emacs running on
some operating system (GNU/Linux, we hope)?  If not, what else does
the user need to have?

Does it require the user to have a portable phone?

Do those email services plan to require two-factor authentication
or offer it as an option for the user?

Are there free implementations of OAuth 2.0?  What are their licenses?

--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Richard Stallman
In reply to this post by Thomas Fitzsimmons-2
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

This is alarming news.  If these reports are correct, they mean that
Google will entirely cut off access to Gmail from the Free World.

Can you find a web page that describes the danger in a clear way,
with references to substantiate the warning?  That is the first thing
we need in order to campaign to convince Google not to do it.

--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Richard Stallman
In reply to this post by Noam Postavsky
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > There is something called xoauth2, is that related? Someone posted a
  > package for it, but the docs are a bit thin...

  > https://github.com/ccrusius/auth-source-xoauth2

I read the response to your message, but I could not tell whether it
involves some nonfree software.  Does it?

--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Stefan Kangas
In reply to this post by Richard Stallman
Richard Stallman <[hidden email]> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> This is alarming news.  If these reports are correct, they mean that
> Google will entirely cut off access to Gmail from the Free World.
>
> Can you find a web page that describes the danger in a clear way,
> with references to substantiate the warning?  That is the first thing
> we need in order to campaign to convince Google not to do it.

Here are two relevant announcements, I think:

Turning off less secure app access to G Suite accounts
https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html

Less secure app turn-off suspended until further notice
https://gsuiteupdates.googleblog.com/2020/03/less-secure-app-turn-off-suspended.html

In the second of them, we read:

    Last December, we announced that we’d be turning off less secure app
    (LSA) access to G Suite accounts, and that you should migrate to OAuth
    authentication instead. The first phase of the LSA turn-down was
    scheduled for June 15, 2020. As many organizations deal with the impact
    of COVID-19 and are now focused on supporting a remote workforce, we
    want to minimize potential disruptions for customers unable to complete
    migrations in this timeframe.

    As a result, we are suspending the LSA turn-off until further
    notice. All previously announced timeframes no longer apply.

So I guess this means that in the mid-term, people should seriously
consider leaving Google.

Hope that helps.

Best regards,
Stefan Kangas



Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Thomas Fitzsimmons-2
In reply to this post by Richard Stallman
Hi Richard,

Richard Stallman <[hidden email]> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Some email services seem to be moving toward requiring MUAs to support
>   > OAuth 2.0, one reason being that they would like MUAs to do two factor
>   > authentication.  It would be nice to have this capability in Gnus's
>   > nnimap.
>
> This may raise some moral issues -- depending on what practical
> requirements there are.  Would you like to explain to me how the
> two-factor authentication works in practice, and what the user needs
> to have?

Thanks for having a look at this bug report.

I could explain in a general way how this might work for Gnus's nnimap
backend.  However, given what I've learned from Lars's and David's
responses, I would prefer to keep this bug report solely about OAuth 2.0
support, with a focus on Google's email services.

Two factor authentication can be implemented by a service without
requiring OAuth 2.0, and vice versa.  (Given what I've learned from Lars
and David I probably should not have even mentioned it in the initial
report.)  Therefore I think lumping the two concepts together in this
bug report will be too confusing.

We could open a new bug report, or open a discussion on emacs-devel,
about two factor authentication support in Emacs generally.  However, I
don't have a specific example to discuss or a bug to report about a
specific service, so I don't think the resulting discussion would be
focused enough to be productive.

Thomas



Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Thomas Fitzsimmons-2
In reply to this post by Stefan Kangas
Hi Stefan,

Stefan Kangas <[hidden email]> writes:

> Richard Stallman <[hidden email]> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>> This is alarming news.  If these reports are correct, they mean that
>> Google will entirely cut off access to Gmail from the Free World.
>>
>> Can you find a web page that describes the danger in a clear way,
>> with references to substantiate the warning?  That is the first thing
>> we need in order to campaign to convince Google not to do it.
>
> Here are two relevant announcements, I think:
>
> Turning off less secure app access to G Suite accounts
> https://gsuiteupdates.googleblog.com/2019/12/less-secure-apps-oauth-google-username-password-incorrect.html
>
> Less secure app turn-off suspended until further notice
> https://gsuiteupdates.googleblog.com/2020/03/less-secure-app-turn-off-suspended.html
>
> [...]

Yes, those are the relevant announcements, thanks.

Quoting from the first announcement:

"If you are using Thunderbird or another email client, re-add your
Google Account and configure it to use IMAP with OAuth."

It seems like Google is acknowledging Thunderbird as a valid option
post-"less-secure-app" turn-off there.

Richard, I think Lars's and David's summary of Thunderbird's situation
highlights the non-technical issues blocking GNU Emacs from supporting
OAuth 2.0 access to the G Suite IMAP service.  I'm wondering if the FSF
could help with those issues.

> So I guess this means that in the mid-term, people should seriously
> consider leaving Google.

Agreed, and I am [1], but maybe a better outcome could be reached.  It
sounds like from Thunderbird's situation, changes to Google's developer
terms of service, giving some consideration to Free Software projects
using these APIs, could solve the problem.

It might take non-technical discussions between the FSF and Google, but
that's one of the FSF's functions, AIUI.  Maybe the result could be a
model for how to handle other similar situations, since Emacs needing
"API keys" to access network services is not unique to G Suite or
Google.

Thomas

1. I'm tempted to try Lars's self-hosted email script. ;-)



Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Richard Stallman
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

It seems to me that the requirement for a secret key in a user program
is fundamentally incompatible with free software.  A free system
cannot keep secrets from the user.  However, if Google is willing to leave a space to use free clients, something could be worked out.

First I have to finish studying all this.  I will send mail now to fetch
those articles.

--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Richard Stallman
In reply to this post by Thomas Fitzsimmons-2
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Two factor authentication can be implemented by a service without
  > requiring OAuth 2.0, and vice versa.

Ok.  But my concern is not about OAuth in particular.  The crucial
question is, will Gmail in the future permit access from the Free World
in any manner whatsoever?

In other words, if we look at all the ways of logging in that Gmail
permits in the future, will _any_ of them be usable in the Free World?

Can you help me find the answer?  If it is no, we had better put all our
strength into changing that answer.



--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Richard Stallman
In reply to this post by Lars Ingebrigtsen
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


  > I don't think there's any way to ship Emacs with built-in oauth2 support
  > for doing auth with Gmail -- it requires distributions with API secrets
  > and stuff, and there's no secrets in the Emacs distribution.

There are no real secrets in any free operating system.  The only way
I know of to have a key and effectively keep it secret with software
is to bury it in a nonfree excutable, and that is not a solution; it
only replaces one impassable obstacle with another impassable
obstacle.

  > Or is there a way to do that now?  I haven't been paying attention the
  > last few months.  I remember Thunderbird including some credentials in
  > the source code and saying, jokily, "remember, these are secret".
  > Somebody would have to register the Emacs "app" with Google, and for
  > Emacs, that would have to be the FSF, right?  And I don't see that
  > happening ever, ideologically.

If what Thunderbird is doing does not involve nonfree software,
I see no reason we couldn't do the same.

But I doubt that Google will continue accepting this forever.  Google
might eventually decide to kick off Thunderbird users, and Gnus users
along with them.

  > But somebody could definitely write a package and put that on MELPA, and
  > do the registration, I think?  (With the same joke, of course.)

To the extent that this approach is usable, we woultn't need to
relegate it to MELPA.  We could put it straight into Gnus.

The two Google announcements clearly describe how Google plans to
block access with anything other than OAuth 2.  They don't go into
much detail about what OAuth 2 requires, and don't describe how this
conflicts with free software.

Can someone find a page describing this issue in a careful
and thorough way, written by someone who knows the subject?

Can someone get in touch with a Thunderbird developer or expert
who would like to discuss the issue?

--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Richard Stallman
In reply to this post by Richard Stallman
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > OK, I'll try to help, but I don't know what Google or Gmail will do in
  > the future, in general, obviously.

I don't expect you to practice precognition.  But it may be possible
to deduce something by putting their announcements together with other
known facts.  Maybe we could figure out questions to ask them.

  > Your question reminded me that Gmail provides "basic HTML view" which
  > does not require any Javascript whatsoever for sign-in or for the main
  > interface, and thus is fully useable with Emacs Web Wowser (eww).

That is a significant fact.  It means that using Gmail in the free
world won't become entirely impossible.  Thanks.
 
So I modify the question:

   Will Gmail in the future permit access from the Free World
   to read mail with a free local MUA in any manner whatsoever?
   
And there is another followup question:

Is it possible to log in on basic HTML view
passing via a proxy that will hide your actual location?
It is possible that basic HTML view won't allow this.

--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

David Engster
In reply to this post by Richard Stallman
> The two Google announcements clearly describe how Google plans to
> block access with anything other than OAuth 2.  They don't go into
> much detail about what OAuth 2 requires, and don't describe how this
> conflicts with free software.
>
> Can someone find a page describing this issue in a careful
> and thorough way, written by someone who knows the subject?

I've described the main issue in another mail in this bug thread. The
problem is that Google's terms of service explicitly forbid to put
client IDs into "open source projects". You can read their terms of
service here:

  https://developers.google.com/terms

Section 4b, paragraph 1:

  Developer credentials (such as passwords, keys, and client IDs) are
  intended to be used by you and identify your API Client. You will keep
  your credentials confidential and make reasonable efforts to prevent and
  discourage other API Clients from using your credentials. Developer
  credentials may not be embedded in open source projects.

So for authors of (F)OSS non-web applications, this in effect makes it
impossible to use OAuth2 with Google services if a client id/secret is
required. The client id/secret is used to identify the application that
is making the request.

-David



Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Richard Stallman
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   https://developers.google.com/terms

  > Section 4b, paragraph 1:

That makes it pretty clear.  Thanks.

I will see what we can do.


--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Thomas Fitzsimmons-2
In reply to this post by Richard Stallman
Richard Stallman <[hidden email]> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > OK, I'll try to help, but I don't know what Google or Gmail will do in
>   > the future, in general, obviously.
>
> I don't expect you to practice precognition.  But it may be possible
> to deduce something by putting their announcements together with other
> known facts.  Maybe we could figure out questions to ask them.
>
>   > Your question reminded me that Gmail provides "basic HTML view" which
>   > does not require any Javascript whatsoever for sign-in or for the main
>   > interface, and thus is fully useable with Emacs Web Wowser (eww).
>
> That is a significant fact.  It means that using Gmail in the free
> world won't become entirely impossible.  Thanks.
>  
> So I modify the question:
>
>    Will Gmail in the future permit access from the Free World
>    to read mail with a free local MUA in any manner whatsoever?
>    
> And there is another followup question:
>
> Is it possible to log in on basic HTML view
> passing via a proxy that will hide your actual location?

Yes.  Here is the recipe I tested:

   sudo apt install proxychains
   sudo sed 's/#quiet_mode/quiet_mode/' -i /etc/proxychains.conf
   ssh -ND 9050 <host-from-which-to-access-mail> &
   HOME=$(mktemp -d) proxychains emacs -Q -nw
   M-x eww RET https://gmail.com RET
   [Use the usual web-based log-in procedure via Emacs Web Wowser.]

The log-in procedure was successful and I was able to use the basic HTML
view interface.

To confirm the results of the test, I also logged into the same service
via Firefox and a direct connection.  After I did the procedure above,
the Firefox session showed:

"This account is currently being used in 1 other location (<address>)."

Where <address> was the IP address of <host-from-which-to-access-mail>.

The above is just an example, other methods may be superior in various
ways, but I think this proves that Gmail is useable in Emacs Web Wowser
via a proxy.

Thomas

P.S. Prior to installing proxychains, I tried using Emacs's built-in
proxy support in the same way.  There are references to SOCKS in the URL
manual, but I couldn't find an easy way to make EWW use localhost:9050
as a SOCKS proxy.  I debugged until I got to the comment "Should check
for socks" in url-default-find-proxy-for-url.



Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Richard Stallman
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Is it possible to log in on basic HTML view
  > > passing via a proxy that will hide your actual location?

  > Yes.  Here is the recipe I tested:

That is a little less bad.

Is there any positive indication that Google will let people continue
using this basic HTML mode?

I wonder -- is it possible for a program talking to that proxy to
convert the messages in the Gmail server into a mailbox file which you
could then pass to an MUA?


--
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)





Reply | Threaded
Open this post in threaded view
|

bug#41386: 28.0.50; Gnus nnimap OAuth 2.0 support

Thomas Fitzsimmons-2
Richard Stallman <[hidden email]> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > Is it possible to log in on basic HTML view
>   > > passing via a proxy that will hide your actual location?
>
>   > Yes.  Here is the recipe I tested:
>
> That is a little less bad.
>
> Is there any positive indication that Google will let people continue
> using this basic HTML mode?

It seems like basic HTML view is the old mode that is still being
maintained.  Just after logging in, an HTML page mentions that "standard
view" requires JavaScript and that to use standard view one must enable
JavaScript.  But the same page then provides the option, "To use [...]
basic HTML view, which does not require JavaScript, click here.".  After
logging in, one can set basic HTML as the default view.  So it seems
like it is still fully supported.

(As an aside: basic HTML view uses old HTML-table-based, rather than new
CSS-based, layout, so it lays out nicely in EWW; in other words, it
provides a user interface that is friendly to simple browsers.  It's by
no means an efficient alternative to Emacs's native MUAs though.)

> I wonder -- is it possible for a program talking to that proxy to
> convert the messages in the Gmail server into a mailbox file which you
> could then pass to an MUA?

I don't see a way of downloading mailbox files via simple links.

It is technically possible to implement the conversion you're
describing, since one can click through several links for a given
message and eventually get the original text.  However, it would be an
awkward, fragile HTML-scraping-type implementation that I don't expect
would be viable in practice.

Thomas



12