<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Twitter, OAuth and Passwords &#8211; Oh My!</title>
	<atom:link href="http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/feed/" rel="self" type="application/rss+xml" />
	<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/</link>
	<description>Mobiles, Shakespeare, Politics, Usability.</description>
	<lastBuildDate>Sun, 14 Mar 2010 20:07:56 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Abraham Williams</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-5302</link>
		<dc:creator>Abraham Williams</dc:creator>
		<pubDate>Sun, 28 Feb 2010 00:02:13 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-5302</guid>
		<description>If you authorized a single service multiple times they get the same access tokens. During the early beta a sequential authorizations would negate the previous ones making desktop apps on multiple computers impossible to use.</description>
		<content:encoded><![CDATA[<p>If you authorized a single service multiple times they get the same access tokens. During the early beta a sequential authorizations would negate the previous ones making desktop apps on multiple computers impossible to use.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Abraham Williams</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-5301</link>
		<dc:creator>Abraham Williams</dc:creator>
		<pubDate>Sat, 27 Feb 2010 23:56:43 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-5301</guid>
		<description>Currently forever. I believe Twitter is looking into limiting them though.</description>
		<content:encoded><![CDATA[<p>Currently forever. I believe Twitter is looking into limiting them though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wolfstar: public relations (PR), social media and word of mouth (WOM) marketing and communications : Wolfstar</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-5278</link>
		<dc:creator>Wolfstar: public relations (PR), social media and word of mouth (WOM) marketing and communications : Wolfstar</dc:creator>
		<pubDate>Fri, 26 Feb 2010 16:08:15 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-5278</guid>
		<description>[...] · Now click on ‘connections’ and anything that you don’t recognise click ‘revoke access’ (OAuth is explained in more detail here) [...]</description>
		<content:encoded><![CDATA[<p>[...] · Now click on ‘connections’ and anything that you don’t recognise click ‘revoke access’ (OAuth is explained in more detail here) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Identity Security - TechnoPhobia</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-5277</link>
		<dc:creator>Identity Security - TechnoPhobia</dc:creator>
		<pubDate>Fri, 26 Feb 2010 14:15:52 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-5277</guid>
		<description>[...] a security risk when people don’t realise that this control must be managed and monitored. This great post from Terrence Eden explains [...]</description>
		<content:encoded><![CDATA[<p>[...] a security risk when people don’t realise that this control must be managed and monitored. This great post from Terrence Eden explains [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rikki</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-5275</link>
		<dc:creator>Rikki</dc:creator>
		<pubDate>Fri, 26 Feb 2010 11:48:02 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-5275</guid>
		<description>I agree, this Is certainly not something I had thought of, so I&#039;d like Twitter to warn me. It&#039;s not a bug, just a usage anomoly. Change will probably only occur when this is actually exploited.

I can&#039;t believe how much comment abuse you&#039;re getting!</description>
		<content:encoded><![CDATA[<p>I agree, this Is certainly not something I had thought of, so I&#8217;d like Twitter to warn me. It&#8217;s not a bug, just a usage anomoly. Change will probably only occur when this is actually exploited.</p>
<p>I can&#8217;t believe how much comment abuse you&#8217;re getting!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Pack</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-5271</link>
		<dc:creator>Mark Pack</dc:creator>
		<pubDate>Fri, 26 Feb 2010 09:07:46 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-5271</guid>
		<description>Oscar: I know about it, you know about it - but is that really enough? If spam and phishing can spread widely because people aren&#039;t as well up on using Twitter as you or me, then that&#039;s a problem - because for a service that gets widespread use, there are always going to be large numbers of not very IT savvy people using it.

Why hasn&#039;t Twitter taken the simple step of providing a tick box option when you change your password to also revoke or not the OAuth permissions? I guess we may argue over what the default on that should be :-)  But expect people to understand that changing their password isn&#039;t enough is just asking for trouble.</description>
		<content:encoded><![CDATA[<p>Oscar: I know about it, you know about it &#8211; but is that really enough? If spam and phishing can spread widely because people aren&#8217;t as well up on using Twitter as you or me, then that&#8217;s a problem &#8211; because for a service that gets widespread use, there are always going to be large numbers of not very IT savvy people using it.</p>
<p>Why hasn&#8217;t Twitter taken the simple step of providing a tick box option when you change your password to also revoke or not the OAuth permissions? I guess we may argue over what the default on that should be :-)  But expect people to understand that changing their password isn&#8217;t enough is just asking for trouble.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob Cawte</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-4315</link>
		<dc:creator>Rob Cawte</dc:creator>
		<pubDate>Sun, 17 Jan 2010 10:15:44 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-4315</guid>
		<description>What I don&#039;t get here is that Twitter told _you_  that they believed your account had been compromised.  I may be well off here, but doesn&#039;t this that they probably had a pretty good idea _how_ it had been compromised - when and through what service.  If this is the case, then they owe it to you to pass that nugget of information along, and perhaps even revoke (or suspend?) the token for the suspect service.  

They didn&#039;t give you an idea of what triggered this alert?</description>
		<content:encoded><![CDATA[<p>What I don&#8217;t get here is that Twitter told _you_  that they believed your account had been compromised.  I may be well off here, but doesn&#8217;t this that they probably had a pretty good idea _how_ it had been compromised &#8211; when and through what service.  If this is the case, then they owe it to you to pass that nugget of information along, and perhaps even revoke (or suspend?) the token for the suspect service.  </p>
<p>They didn&#8217;t give you an idea of what triggered this alert?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rabble</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2786</link>
		<dc:creator>rabble</dc:creator>
		<pubDate>Thu, 05 Nov 2009 17:33:54 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2786</guid>
		<description>I agree that twitter needs to do a better job at showing what activity an app is doing on your behalf via oauth. With Fire Eagle we show latest updates / use per authorized application. 

Calling them connections is confusing. And they don&#039;t provide any audit of what these applications have been doing. It&#039;d also be good if there were a note / link from the password rest page to the connections page. 

But this is a relatively minor UX change. Not a security problem in OAuth. We should be following best practices. Which i did with my implementation.</description>
		<content:encoded><![CDATA[<p>I agree that twitter needs to do a better job at showing what activity an app is doing on your behalf via oauth. With Fire Eagle we show latest updates / use per authorized application. </p>
<p>Calling them connections is confusing. And they don&#8217;t provide any audit of what these applications have been doing. It&#8217;d also be good if there were a note / link from the password rest page to the connections page. </p>
<p>But this is a relatively minor UX change. Not a security problem in OAuth. We should be following best practices. Which i did with my implementation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: heise online &#8211; Hintertür bei Twitter schließen &#171; Rolf Schaumburg&#39;s privater Blog</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2779</link>
		<dc:creator>heise online &#8211; Hintertür bei Twitter schließen &#171; Rolf Schaumburg&#39;s privater Blog</dc:creator>
		<pubDate>Thu, 05 Nov 2009 09:31:17 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2779</guid>
		<description>[...] worden sei. Doch nachdem er damit sozusagen das Schloss der Eingangstür getauscht hatte, stellte er fest, dass der Dienstbotenzugang in Form der OAuth-Anmeldung nach wie vor sperrangelweit offen [...]</description>
		<content:encoded><![CDATA[<p>[...] worden sei. Doch nachdem er damit sozusagen das Schloss der Eingangstür getauscht hatte, stellte er fest, dass der Dienstbotenzugang in Form der OAuth-Anmeldung nach wie vor sperrangelweit offen [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Terence Eden</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2778</link>
		<dc:creator>Terence Eden</dc:creator>
		<pubDate>Thu, 05 Nov 2009 09:15:19 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2778</guid>
		<description>Hi Adam,

Let&#039;s say you legitimately use OAuth with, say, &lt;a href=&quot;http://m.dabr.co.uk/&quot; rel=&quot;nofollow&quot;&gt;Dabr&lt;/a&gt; on your home PC.
You then go to work and use OAuth with Dabr on your work Mac.
Same site, different computers and IP addresses - but no difference in functionality.  You just get the OAuth prompt.  This is the way it is supposed to work, you may want to be logged in from multiple locations.

I think Twitter showing &lt;em&gt;how many&lt;/em&gt; tokens you&#039;ve authorised for each service may be a better idea than what they do currently.  That way, you could revoke the token for a malicious user without having to revoke all of your tokens for a specific site.

It&#039;s a knotty usability problem, that&#039;s for sure.

T</description>
		<content:encoded><![CDATA[<p>Hi Adam,</p>
<p>Let&#8217;s say you legitimately use OAuth with, say, <a href="http://m.dabr.co.uk/" rel="nofollow">Dabr</a> on your home PC.<br />
You then go to work and use OAuth with Dabr on your work Mac.<br />
Same site, different computers and IP addresses &#8211; but no difference in functionality.  You just get the OAuth prompt.  This is the way it is supposed to work, you may want to be logged in from multiple locations.</p>
<p>I think Twitter showing <em>how many</em> tokens you&#8217;ve authorised for each service may be a better idea than what they do currently.  That way, you could revoke the token for a malicious user without having to revoke all of your tokens for a specific site.</p>
<p>It&#8217;s a knotty usability problem, that&#8217;s for sure.</p>
<p>T</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Adam Cohen-Rose</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2772</link>
		<dc:creator>Adam Cohen-Rose</dc:creator>
		<pubDate>Wed, 04 Nov 2009 21:07:49 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2772</guid>
		<description>What exactly happens when the imposter goes to authenticate themselves on a site that you&#039;ve already authorized using OAuth? As pzupan says above, twitter could at least say when the last authorization happened. They could also keep a count of authorizations for each site, so if you know you&#039;ve only been through the process once on each, you&#039;d be able to see immediately which one has been compromised.</description>
		<content:encoded><![CDATA[<p>What exactly happens when the imposter goes to authenticate themselves on a site that you&#8217;ve already authorized using OAuth? As pzupan says above, twitter could at least say when the last authorization happened. They could also keep a count of authorizations for each site, so if you know you&#8217;ve only been through the process once on each, you&#8217;d be able to see immediately which one has been compromised.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Carrington</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2770</link>
		<dc:creator>David Carrington</dc:creator>
		<pubDate>Wed, 04 Nov 2009 19:06:41 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2770</guid>
		<description>That doesn&#039;t actually avoid the problem though. If someone else finds out your password then *they* can authorise a site that you&#039;re not aware of and keep (some) control of your account through that site until someone tells you to manually check your OAuth connections page and revoke access.

That&#039;s hardly an ideal situation and is still a security issue.</description>
		<content:encoded><![CDATA[<p>That doesn&#8217;t actually avoid the problem though. If someone else finds out your password then *they* can authorise a site that you&#8217;re not aware of and keep (some) control of your account through that site until someone tells you to manually check your OAuth connections page and revoke access.</p>
<p>That&#8217;s hardly an ideal situation and is still a security issue.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Neil Kandalgaonkar</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2769</link>
		<dc:creator>Neil Kandalgaonkar</dc:creator>
		<pubDate>Wed, 04 Nov 2009 18:51:35 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2769</guid>
		<description>Hey, thanks for the insight. I just noticed that Google Docs has a similar bug; if you change the password on your Google Account, they don&#039;t delete all of your documents. I mean, who knows what an impostor might have been doing?</description>
		<content:encoded><![CDATA[<p>Hey, thanks for the insight. I just noticed that Google Docs has a similar bug; if you change the password on your Google Account, they don&#8217;t delete all of your documents. I mean, who knows what an impostor might have been doing?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Havard</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2767</link>
		<dc:creator>John Havard</dc:creator>
		<pubDate>Wed, 04 Nov 2009 18:31:31 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2767</guid>
		<description>You&#039;ve confused authentication and authorization.  They are not the same thing.  Your username and password are all about authentication, proving you are you, or at least know your password.  OAuth is about authorization, i.e. giving another site permission to act on your behalf without exposing your authentication credentials.</description>
		<content:encoded><![CDATA[<p>You&#8217;ve confused authentication and authorization.  They are not the same thing.  Your username and password are all about authentication, proving you are you, or at least know your password.  OAuth is about authorization, i.e. giving another site permission to act on your behalf without exposing your authentication credentials.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jamie</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2765</link>
		<dc:creator>Jamie</dc:creator>
		<pubDate>Wed, 04 Nov 2009 18:08:07 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2765</guid>
		<description>I&#039;m a dev and I have no idea how to manually revoke an OAuth token. Maybe my grandma can figure it out and explain to me.</description>
		<content:encoded><![CDATA[<p>I&#8217;m a dev and I have no idea how to manually revoke an OAuth token. Maybe my grandma can figure it out and explain to me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dossy Shiobara</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2764</link>
		<dc:creator>Dossy Shiobara</dc:creator>
		<pubDate>Wed, 04 Nov 2009 17:43:46 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2764</guid>
		<description>&quot;But if someone does have your password, and uses OAuth before you have a chance to change it, they will still have access to your account even after the password has changed.&quot;

... until you revoke the OAuth token for that third-party application and then re-authorize it with a new OAuth token, which is the way it&#039;s supposed to work.

Twitter could make it easier on users who get pwnt by providing a &quot;de-authorize all applications&quot; function.</description>
		<content:encoded><![CDATA[<p>&#8220;But if someone does have your password, and uses OAuth before you have a chance to change it, they will still have access to your account even after the password has changed.&#8221;</p>
<p>&#8230; until you revoke the OAuth token for that third-party application and then re-authorize it with a new OAuth token, which is the way it&#8217;s supposed to work.</p>
<p>Twitter could make it easier on users who get pwnt by providing a &#8220;de-authorize all applications&#8221; function.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Carrington</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2763</link>
		<dc:creator>David Carrington</dc:creator>
		<pubDate>Wed, 04 Nov 2009 17:32:17 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2763</guid>
		<description>As Terence knows, I made a Twitter app which (optionally) uses OAuth. I know that the OAuth connections page exists and I understand that changing my password does not automatically revoke any OAuth tokens that have already been approved. A typical user has a much narrower understanding of how OAuth works.

I do agree that this *is* a security issue and that it needs to be clearer to users that simply changing their password is no longer enough to block someone from using their account.

IMO an automatic revoke of all tokens is too disruptive. Dossy gets it spot on when suggesting that if you change your password then you should be given some information about OAuth and how to further protect yourself.</description>
		<content:encoded><![CDATA[<p>As Terence knows, I made a Twitter app which (optionally) uses OAuth. I know that the OAuth connections page exists and I understand that changing my password does not automatically revoke any OAuth tokens that have already been approved. A typical user has a much narrower understanding of how OAuth works.</p>
<p>I do agree that this *is* a security issue and that it needs to be clearer to users that simply changing their password is no longer enough to block someone from using their account.</p>
<p>IMO an automatic revoke of all tokens is too disruptive. Dossy gets it spot on when suggesting that if you change your password then you should be given some information about OAuth and how to further protect yourself.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Terence Eden</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2761</link>
		<dc:creator>Terence Eden</dc:creator>
		<pubDate>Wed, 04 Nov 2009 16:59:53 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2761</guid>
		<description>Hi,

I know I&#039;m an idiot. Most people are.  Good security design requires you to fit to your users&#039; expectations and limitations or invest heavily in educating them.  It&#039;s why &lt;a href=&quot;http://www.schneier.com/blog/archives/2005/06/write_down_your.html&quot; rel=&quot;nofollow&quot;&gt;writing down passwords is often more secure&lt;/a&gt; than choosing weak, but easily memorable passwords.  People are idiots and can&#039;t remember things.

In this case, OAuth tokens are a completely new way of thinking for most users.  Twitter should take that into account when asking them to reset their passwords.

Tell me, assuming you use OAuth, how would you tell which one of your previously authorised sites was compromised?

T
PS You&#039;ll notice a distinct lack of adverts on this site - I&#039;m not sure what good SEO would do me. Unless you want to buy me something from my Amazon wishlist?</description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>I know I&#8217;m an idiot. Most people are.  Good security design requires you to fit to your users&#8217; expectations and limitations or invest heavily in educating them.  It&#8217;s why <a href="http://www.schneier.com/blog/archives/2005/06/write_down_your.html" rel="nofollow">writing down passwords is often more secure</a> than choosing weak, but easily memorable passwords.  People are idiots and can&#8217;t remember things.</p>
<p>In this case, OAuth tokens are a completely new way of thinking for most users.  Twitter should take that into account when asking them to reset their passwords.</p>
<p>Tell me, assuming you use OAuth, how would you tell which one of your previously authorised sites was compromised?</p>
<p>T<br />
PS You&#8217;ll notice a distinct lack of adverts on this site &#8211; I&#8217;m not sure what good SEO would do me. Unless you want to buy me something from my Amazon wishlist?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Whatley</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2759</link>
		<dc:creator>James Whatley</dc:creator>
		<pubDate>Wed, 04 Nov 2009 16:56:49 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2759</guid>
		<description>Nothing quite like expert and informed opinion. 
As in, Rabble, your troll-like comment is in fact, nothing like it. 

Terence, good point - well made. I did wonder about OAuth the other day when something like this happened to a friend of mind. Sad to hear my suspicion has proved correct.</description>
		<content:encoded><![CDATA[<p>Nothing quite like expert and informed opinion.<br />
As in, Rabble, your troll-like comment is in fact, nothing like it. </p>
<p>Terence, good point &#8211; well made. I did wonder about OAuth the other day when something like this happened to a friend of mind. Sad to hear my suspicion has proved correct.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rabble</title>
		<link>http://shkspr.mobi/blog/index.php/2009/11/twitter-oauth-and-passwords-oh-my/#comment-2758</link>
		<dc:creator>rabble</dc:creator>
		<pubDate>Wed, 04 Nov 2009 16:42:37 +0000</pubDate>
		<guid isPermaLink="false">http://shkspr.mobi/blog/?p=994#comment-2758</guid>
		<description>You&#039;re an idiot.

This is not a security hole. This is a feature. It&#039;s the way OAuth is designed. 

Should twitter make it clearer how applications are posting to your account, and make it easier to see and revoke tokens. Sure. But they already do that, just maybe not as clearly as you&#039;d like.

Posts like this are sensationalist SEO spam.</description>
		<content:encoded><![CDATA[<p>You&#8217;re an idiot.</p>
<p>This is not a security hole. This is a feature. It&#8217;s the way OAuth is designed. </p>
<p>Should twitter make it clearer how applications are posting to your account, and make it easier to see and revoke tokens. Sure. But they already do that, just maybe not as clearly as you&#8217;d like.</p>
<p>Posts like this are sensationalist SEO spam.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
