Multiple issues on iPad Pro

Dear all,

I realise that using 1Password.com in Safari on an iPad Pro is a bit of an edge-case. Nevertheless, I can imagine many situations in which this is useful, desirable, and even necessary. For example, a misguided administrator may decide to switch to iPad full time — I am guilty of this — or simply be on-the-go with a 4G-enabled iPad and no Mac at hand — something which frequently happened to me as I bounced back-and-forth between sites.

On the whole, the new 1Password web application works quite well and the recent redesign seems to have improved things dramatically. However — and that is a big however — many things are subtly wrong, including essential tap targets.

While some links and buttons work, the vast majority require tapping about 5 mm above the actual target, making certain areas of the interface extremely difficult to access. For example, the account pop-over at the top right is so high up on the page that the actual target for the link to the Profile page sits at the edge of the page.

Would the web app team take a few moments to try using the web application on Mobile Safari? The problem is so beautifully systematic that I assume it could be traced to a few CSS selectors or a common mistake in some JavaScript layout math. Until it is fixed, using the app is quite tiresome — not to mention possibly dangerous as some tap targets are overlaid on top of the wrong links and buttons.

As an aside, there is still no way to properly log out of 1Password.com. Even tapping the "Logout" button will keep the device authenticated. It is necessary to log in again to de-authorise the session — by which time one has created yet another web session from which it is impossible to truly log out. I understand that 1Password.com wants to retain a copy of the account key by default and make it as "sticky" as possible, but there ought to be a way to completely destroy sessions upon logout: all my users, at the moment, have one ghost web session to their credit.

— FJ


1Password Version: 379
Extension Version: Not Provided
OS Version: 10.3.3
Sync Type: 1Password for Teams

Comments

  • john_mjohn_m

    Team Member

    Hi @francoisjoseph! Thanks for providing your detailed feedback! We know it takes time, thought and energy on your part to send to us, and we always find our customer feedback really valuable, so on behalf of everyone here, thank you! :chuffed:

    Using 1Password through Safari on iOS is probably a lot less common than using our native app, but we do still support it, so I'll be happy to talk to you about it!

    I don't have access to an iPad Pro myself, but I do have an iPad Air (iOS 10.3.3); so for reference, here's a screenshot I just took of our web interface running on my iPad for my own individual account:

    I took the screenshot while holding down the link to view the "My Profile" page. For myself, I didn't have any difficulty tapping on the link; I tried several times, and each time my tap successfully hit the correct target. Are you experiencing something different with your iPad Pro? You can reveal the tap target by simply tapping and holding your finger on the link; while continuing to hold your finger, you can then take a screenshot using the usual iOS device method.

    In regards to the second point you mentioned regarding the caching of the Secret Key; we do this as as both part of our security design (the Secret Key is a device secret), as well as a user convenience. If you would like a web browser not to store the Secret Key, then you can check the box "This is a public or shared computer" under the Master Password field when signing in, and the Secret Key will not be cached (if that option isn't showing for you, then tap the "Change Accounts" link under the "Sign In" button). Account members can de-authorise devices (including browsers) at any time via their "My Profile" page in the web interface for the account.

    I hope that helps! :+1:

  • Hello, @John_M, and thank you for your kind reply! :)

    The correct behaviour which you mention appears to be intermittent. I just logged back into the 1Password web app using the exact same setup — vanilla Safari without content blockers — and tap targets work as you say, even though they most definitely did not before — and across multiple logins to boot. Could there be an issue with Mobile Safari subtly zooming the page at some point and the interface not responding properly to the change in zoom level? This is quite mysterious, but I am sure I did not dream the original issue. :scream:

    There is still a persistent issue with menus, though, including the one you highlight in your screenshot. For me, once these menus appear, the only way to dismiss them is to select one of the items they offer or to navigate away from the page completely. No amount of tapping outside of them can dismiss them. :dizzy:

    As an aside, I just noticed there is one group called Team Members which appears in my main list of groups, but not in the right hand-side column. Is this by design? Does this group have a special status? I use this group for Account Recovery and am worried that it may not be set up properly, locking out anybody who might need their account recovered… :sweat:

    Account members can de-authorise devices, but never their last signed-in device. As far as I can see, the last web session always remains open indefinitely. As I mentioned before, all my users have one ghost web session to their credit, which I cannot invalidate as an administrator and which they cannot invalidate since they have logged out of the browser. I admit that I fail to see the point: if I log out of a browser and clear its cookies and database, thereby ensuring I will never be able to reuse it, what is the point of the 1Password web app holding onto the session? :crazy:

    Thanks again! :)

    — FJ

  • john_mjohn_m

    Team Member

    No problem, @francoisjoseph, I'm always happy to help! :chuffed:

    The correct behaviour which you mention appears to be intermittent. I just logged back into the 1Password web app using the exact same setup — vanilla Safari without content blockers — and tap targets work as you say, even though they most definitely did not before — and across multiple logins to boot. Could there be an issue with Mobile Safari subtly zooming the page at some point and the interface not responding properly to the change in zoom level? This is quite mysterious, but I am sure I did not dream the original issue. :scream:

    That is strange! I'll do some more playing around myself, but if you are able to recreate the issue, it would be great if you could take a screenshot of the tap-target you have at the time and send it on to us! That's definitely something we'd want to take a look at and address.

    There is still a persistent issue with menus, though, including the one you highlight in your screenshot. For me, once these menus appear, the only way to dismiss them is to select one of the items they offer or to navigate away from the page completely. No amount of tapping outside of them can dismiss them. :dizzy:

    That's strange! Assuming you're referring to the menu in my screenshot above with "My Profile", "Import", etc., then on my iPad, tapping my profile name again ("John Mellerick" in my screenshot above) closes the menu. Does that work on your device? If not, I wonder if maybe Safari on your device has cached some CSS for the site from before the redesign, and has not properly refreshed it? I know the desktop version of Safari can do that occasionally. You could try clearing Safari's website data via the Settings app, and see if that helps!

    As an aside, I just noticed there is one group called Team Members which appears in my main list of groups, but not in the right hand-side column. Is this by design? Does this group have a special status? I use this group for Account Recovery and am worried that it may not be set up properly, locking out anybody who might need their account recovered… :sweat:

    Yes, the "Team Members" group is indeed a special group; it's one of the three built-in groups that come with every 1Password Teams account. Every full-member of your account (not Guests) is automatically a part of "Team Members", and cannot be removed from it. The "Team Members" group can be configured with the default vault access for every member of the account, and additionally with Teams Pro, can be configured with any additional role permissions if you like. The list of groups specifically called out in the sidebar of the new redesign are the groups that you, as the signed-in member, have been assigned explicit management control over. As all account members have explicit "Member" permissions in "Team Members", which cannot be changed, it does not show up. Account owners have implicit management permissions on the group, which is why it also does not show up in the sidebar for them. It can always be accessed by clicking on the "Groups" heading in the sidebar.

    Account members can de-authorise devices, but never their last signed-in device. As far as I can see, the last web session always remains open indefinitely. As I mentioned before, all my users have one ghost web session to their credit, which I cannot invalidate as an administrator and which they cannot invalidate since they have logged out of the browser. I admit that I fail to see the point: if I log out of a browser and clear its cookies and database, thereby ensuring I will never be able to reuse it, what is the point of the 1Password web app holding onto the session? :crazy:

    Ah! I think there is a small misunderstanding here - those are authorised devices, not sessions! A "session" with 1Password is terminated automatically whenever you sign out of the web interface, or whenever the web interface or one of our apps lock (either by explicit action by the user, or due to reaching the idle lock timeout or other such mechanism). When 1Password locks or is logged out, the decryption keys formed from the combination of Secret Key and master password are discarded, preventing data from being decrypted any more until the app is unlocked again.

    Access to an account via an account membership requires (amongst other things) knowing the membership's master password (something the person knows) and the membership's unique Secret Key. The Secret Key is not designed to be memorised, and is instead designed to be something stored on a member's devices (something their device has). Only the successful combination of the two (along with the correct sign-in address of the account and membership email address) permits access to the account. Devices that have been used to successfully sign into an account (and therefore have been given the correct Secret Key) are known as authorised devices - they have nothing to do with sessions! Every member that has accessed their account will have at least one authorised device; most folks have more than one (e.g., they might have a web browser, a desktop PC and a mobile device, etc.). Generally speaking, the only time you would want to explicitly de-authorise a device would be if you wanted to prevent that device from being able to access the account again without having the Secret Key re-entered; say for example if a mobile device was lost or stolen. You can learn more about the Secret Key here: https://support.1password.com/secret-key-security/

    Let me know if you have any more questions! :+1:

  • Hello again, @john_m! Thank you, as always, for your kind and detailed reply. :)

    I will be sure to post screenshots, of course, and to let you know. Since I religiously clear Safari's caches, even on the iPad, and usually use Private Mode to log into the 1Password web application — which should guarantee no data is retained from session to session — I would plump for a zooming issue as opposed to a caching one, but that is wild speculation. :lol:

    Thank you for clarifying the status of the Team Members group, it is most interesting. May I suggest that the current design, beautiful as it is, is misleading? The sidebar looks like it reflects all the options available, and indeed it does, as far as I can see, for most sections at least. Excluding one group from the list just makes it look like has fallen through the cracks and creates an uncomfortable amount of inconsistency. It seems to suggest that the sidebar is not so much a navigation tool as a list of shortcuts, especially as, on my screen at least, there are ample amounts of white space remaining at the bottom. This is not much of an issue right now, but, as options and features are added to the web app, having a canonical way of accessing the various settings would be genuinely helpful. Just a thought…

    Speaking of the bar, I notice that the yellow call-outs, such as the one highlighting the new design, are sticky. I have clicked on the announcement many times and read the little pop-up telling me about the fresh coat of paint — great work, by the way! :+1: — and yet the yellow pad is still here. Could the app possibly remember what has been seen already? Keeping that pad on at all times makes users all the more likely to miss subsequent updates…

    I am indeed guilty of using sloppy language, for which I apologise. I did mean devices, not sessions and I appreciate your gently reminding me of the difference. My original comments hold, though: if I log into 1Password, then log out of it, my browser is forcefully retained as a trusted "device," even though I may have been using it in Private mode and the master key might have been cleared out the minute I closed the last window. This creates a false sense of security by making it look as if users had more authorised devices than they really do. It also seems rather pointless to assume that the a browser retains a key while the web appis really unable to tell whether this is in fact the case. I realise I am flogging a dead horse here, and one nobody is the least bit interested in, but it still feels like there ought to be a way to say "log me out and throw away the key, for I shan't be using this browser any more." Oh well.

    As an aside, and as a free gift with purchase, here is a screenshot of an interesting little bug I have been experiencing ever since signing up for 1Password. I just added a new Member to my team, whose profile does not exhibit this inconsistency, but I cannot get it to go away on my older user accounts. Notice how the user is listed as belonging to a single group, yet the Groups table prominently displays "2." Do you know whether this is solely cosmetic or whether this could be indicative of a deeper issue?

    Thanks again for all your insights! :+1:

    Looking forward to hearing from you,
    — FJ

  • brentybrenty

    Team Member

    @francoisjoseph: I just wanted to chime in here in case it helps, regarding authorized devices. I may also be misunderstanding you, but just to clarify, it isn't possible to remove the browser you're accessing 1Password.com with, since you'll have to have an active session there in order to access the authorize device list. Previously this would give you an error reflecting this if you tried to remove it, but now it will just show as "Your current device" and not give you the option to deauthorize it. You can, however, effectively deauthorize everything by regenerating the Secret Key. Does that help?

    I think you raise a good point about "log me out and throw away the keys" for the device/browser you're using — sort of a retroactive "this is a public computer" checkbox. I haven't seen many requests like this, but it's certainly something we can consider.

    As for the screenshot, yeah this is something we need to find a way to improve, since it is confusing. The count is correct, but it reflects the default "group" which is not modifiable. So this is technically a technical issue rather than UI, but I appreciate that it's something users see that causes confusion.

    Good feedback about the new web interface! Glad to hear you're liking it, but you're right that there's room for improvement. We'll see what we can do to iron out these kinks! :chuffed:

  • Hello, @brenty… May I ask what default group you are talking about? My newly created user, who is only a member of the Team Members group does not exhibit this issue: there is only one group in the table and the header correctly reads "1." Or am I missing something painfully obvious? I know I am rather prone to this… :lol:

  • brentybrenty

    Team Member

    @francoisjoseph: I'm having trouble remembering the details, as it does differ a bit between account types. But just to illustrate, it wasn't long ago that we had a similar issue with individual accounts showing multiple groups. These technically exist, since it's the same tech as 1Password Teams/Families, but obviously groups are not useful in that environment. I'll ask a colleague who works on this stuff behind the scenes more than I do to explain it better than I can. ;)

  • Thank you, @Brenty! I look forward to hearing more about this mysterious group! :crazy:

  • brentybrenty

    Team Member

    @francoisjoseph: Turns out I was right, but I was overthinking it. This is a bug and an issue has been filed after discussing it with the team. The person details page shows an incorrect group count that includes the Recovery group when it's not actually available to the user. We should hide this from the count, since the user is a member of the recovery group technically so others can perform recovery for them, but not in any real sense as far as the user is concerned since they would have to have the correct permissions to be able to perform recovery themselves. Thanks for bringing this up! :)

    ref: B5-3040

  • Hello again, @brenty, and thank you for looking into this deeper. I am sorry to hear that the dreaded Recovery group is making a comeback. I do remember it being an issue when I first signed up for 1Password for Teams and shudder whenever I hear its name.

    Could you tell me what you mean by "the user would have to have the correct permissions to be able to perform recovery themselves?"

  • brentybrenty

    Team Member
    edited August 2017

    @francoisjoseph: Hey, no problem! And the recovery group, while confusing, is a really good thing. ;)

    With all 1Password.com accounts, there is a recovery group. In individual accounts obviously this is useless (since there's no one else) and just a fact of the architecture. But with 1Password Families and Teams accounts, "administrators" (the terminology varies between plans) can perform recovery for other members. So everyone technically is part of the recovery group, even if they do not have the ability to perform recovery, so at least others can for them. This is what you're seeing in the UI. But anyone (okay, not guests) can be promoted to this position so that they can perform recovery for others. And with the 1Password Teams Pro plan, custom groups make it possible to granularly give members recovery permissions without promoting them to an administrative role.

    Does that help? It's definitely a bit confusing, because of the different elements and terminology involved. :chuffed:

  • edited August 2017

    Hello, @Brenty! :)

    Oh, yes, I agree, recovery is a very good thing in itself… A little panicking sometimes — see our other thread :tongue: — but definitely useful. Bacon is too tasty not to be saved on a regular basis. :pirate:

    What I find confusing is that membership in this hidden Recovery group does not signal an ability to perform recovery but rather to be recovered by someone else. Did I get this this right? If so, we are all good. :+1:

    How come I am not seeing this inconsistency for all my users, though? One of my recently created users, whom I assume has been placed in this Recovery group by default so that his account can be recovered, shows the correct number of group memberships on his profile page — there are no discrepancies between the header ("1") and his one and only group ("Team Members"). :dizzy:

    Any thoughts? :chuffed:

  • brentybrenty

    Team Member

    Hello, @Brenty! :) Oh, yes, I agree, recovery is a very good thing in itself… A little panicking sometimes — see our other thread :tongue: — but definitely useful. Bacon is too tasty not to be saved on a regular basis. :pirate:

    @francoisjoseph: Ha! Indeed. ;)

    What I find confusing is that membership in this hidden Recovery group does not signal an ability to perform recovery but rather to be recovered by someone else. Did I get this this right? If so, we are all good. :+1:

    Yeah, I agree. It's something we'll have to address. I think it helps to look at it like a vault. The vault exists and you can still have access to it even if you don't have the ability to manage or write to it. That's not quite the same thing, but if a team member was not part of the recovery group no one could perform recovery for them. It's sort of a public key pool.

    How come I am not seeing this inconsistency for all my users, though? One of my recently created users, whom I assume has been placed in this Recovery group by default so that his account can be recovered, shows the correct number of group memberships on his profile page — there are no discrepancies between the header ("1") and his one and only group ("Team Members"). :dizzy: Any thoughts? :chuffed:

    Yeah that's the whole problem. It isn't consistent. If it were, it would be less confusing. Just imagine my surprise when I logged into my individual account and it showed "2 users". We'll get it fixed! :blush:

This discussion has been closed.