Prerequsite: AITC is enabled and about:config enables myapps dashboard Steps: 1. Go to myapps and login with BID account #1 2. Go to apps.mozillalabs.com/appdir and install an app 3. Close Firefox 4. Restart Firefox 5. Go to myapps and login with BID account #2 6. Delete the app installed from BID account #1 7. Close Firefox 8. Start Firefox with a new profile with the config params set in the prereqs and go to myapps 9. Login with account #1 Expected: The installed app should still be there - the deletion took place while logged in as account #2, not account #1. Actual: The installed app is deleted from account #1. Additional Notes: This bug is a consequence of bug 761821. Fixing that bug may fix this bug as a result.

We cannot fix either bug until we get sign in to the browser, or fix 746204.

Nominating for k9o per the same rationale as bug 746204.

As Anant points out in comment #1 and as I mentioned in a related comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=761821#c2, all of this is expected behavior in our current world where there is no "sign into the browser" feature.

(In reply to Ragavan S [:rags] from comment #3) > As Anant points out in comment #1 and as I mentioned in a related comment > here: https://bugzilla.mozilla.org/show_bug.cgi?id=761821#c2, all of this is > expected behavior in our current world where there is no "sign into the > browser" feature. Unlike bug 761821, this one I disagree - this does not make sense that you should be able to modify app metadata tied to a persona when you are logged out of the account where the data was pulled - the changes should be done locally, not against the cloud. The problem here sounds a lot like we've failed to entirely logout of the original account that we've pulled the data from, so modifications can still be made against the server even though logout has occurred.

A followup point too - Remember sign into browser is out of scope for k9o as of right now (per what I saw on related bugs involving it), so a short-term solution is needed anyways (i.e. we can't rely on it in the short-term, given that AITC is a k9o requirement, sign into browser no longer is, unless that plan is changing again).

(In reply to Jason Smith [:jsmith] from comment #0) > Prerequsite: AITC is enabled and about:config enables myapps dashboard > > Steps: > > 1. Go to myapps and login with BID account #1 > 2. Go to apps.mozillalabs.com/appdir and install an app > 3. Close Firefox > 4. Restart Firefox > 5. Go to myapps and login with BID account #2 > 6. Delete the app installed from BID account #1 > 7. Close Firefox > 8. Start Firefox with a new profile with the config params set in the > prereqs and go to myapps > 9. Login with account #1 How likely is step 8? I understand having more than one BID on the same desktop, but multiple profiles? Is that a common case for people that share a computer?

(In reply to Jennifer Arguello :ticachica from comment #6) > (In reply to Jason Smith [:jsmith] from comment #0) > > 8. Start Firefox with a new profile with the config params set in the > > prereqs and go to myapps > > 9. Login with account #1 > > How likely is step 8? I understand having more than one BID on the same > desktop, but multiple profiles? Is that a common case for people that share > a computer? It is not common, the step was merely intended to simulate the person going to a new computer and signing in with account #1. Two profiles on one computer is (technically) the same as two different computers.

(In reply to Jason Smith [:jsmith] from comment #5) > A followup point too - Remember sign into browser is out of scope for k9o as > of right now (per what I saw on related bugs involving it), so a short-term > solution is needed anyways (i.e. we can't rely on it in the short-term, > given that AITC is a k9o requirement, sign into browser no longer is, unless > that plan is changing again). I do not agree that a short term solution is necessary. It is better to do this the right way and wait for "sign in to the browser". If SITB is not a k9o blocker then this should not a k9o blocker either.

(In reply to Anant Narayanan [:anant] from comment #8) > (In reply to Jason Smith [:jsmith] from comment #5) > > A followup point too - Remember sign into browser is out of scope for k9o as > > of right now (per what I saw on related bugs involving it), so a short-term > > solution is needed anyways (i.e. we can't rely on it in the short-term, > > given that AITC is a k9o requirement, sign into browser no longer is, unless > > that plan is changing again). > > I do not agree that a short term solution is necessary. It is better to do > this the right way and wait for "sign in to the browser". If SITB is not a > k9o blocker then this should not a k9o blocker either. I still don't agree. The concern I have is not UX primarily in this bug, it's security. This opens a security hole for shared computers if we don't implement this in the short term. This use case could happen with a shared public computer: 1. I login with the generic account to the public computer 2. I log into the dashboard with persona #1 3. I install an app 4. I logout of the public computer 5. Evil person logs with generic account to the public computer 6. I log into the dashboard with persona #2 7. I notice there's other apps are shown on the UI and I delete all of them Result - Persona #1 just lost its apps by someone else's interactions Also Note - Just because SITB is not a blocker does not mean that we should diminishing the UX to the user for k9o with AITC. End of the day we have an optimal UX that people will use. Otherwise, we're just building an implementation that does hold value to our end user's needs. I agree SITB is probably the better long term solution, although making that a non-blocker then damages the UX for AITC, unless we have a solution in the short-term that is okay. If we need SITB to have a good UX for AITC, then we should push back to re-nom it for k9o (I already indicated on the bug that's I'm nervous to cut it, given the UX risk it does to AITC). My side disclaimer: Sync UX in firefox has never been good, so I'd rather deliver something that people will use within the k9o milestone, not an implementation that exists but no one will use to meet the "checkmark" to complete the k9o story.

Should clarify that evil person should be referenced in steps 6 and 7.

> 1. I login with the generic account to the public computer > 2. I log into the dashboard with persona #1 > 3. I install an app > 4. I logout of the public computer > 5. Evil person logs with generic account to the public computer > 6. I log into the dashboard with persona #2 > 7. I notice there's other apps are shown on the UI and I delete all of them Ah, okay, this should not occur. Please clarify what you mean by step 4 (I logout of the public computer). If you log out of your Persona, evil person (using persona #2) *should not* be able to delete an app that was installed in persona #1. If they are, then it is a bug, which we should fix (and must block the first release for AITC). Can you re-verify that this is the case?

(In reply to Anant Narayanan [:anant] from comment #11) > > 1. I login with the generic account to the public computer > > 2. I log into the dashboard with persona #1 > > 3. I install an app > > 4. I logout of the public computer > > 5. Evil person logs with generic account to the public computer > > 6. I log into the dashboard with persona #2 > > 7. I notice there's other apps are shown on the UI and I delete all of them > > Ah, okay, this should not occur. Please clarify what you mean by step 4 (I > logout of the public computer). If you log out of your Persona, evil person > (using persona #2) *should not* be able to delete an app that was installed > in persona #1. > > If they are, then it is a bug, which we should fix (and must block the first > release for AITC). Can you re-verify that this is the case? Sure. Flagging qawanted - I'll retest this to be sure.

(In reply to Jason Smith [:jsmith] from comment #12) > (In reply to Anant Narayanan [:anant] from comment #11) > > > 1. I login with the generic account to the public computer > > > 2. I log into the dashboard with persona #1 > > > 3. I install an app > > > 4. I logout of the public computer > > > 5. Evil person logs with generic account to the public computer > > > 6. I log into the dashboard with persona #2 > > > 7. I notice there's other apps are shown on the UI and I delete all of them > > > > Ah, okay, this should not occur. Please clarify what you mean by step 4 (I > > logout of the public computer). If you log out of your Persona, evil person > > (using persona #2) *should not* be able to delete an app that was installed > > in persona #1. > > > > If they are, then it is a bug, which we should fix (and must block the first > > release for AITC). Can you re-verify that this is the case? > > Sure. Flagging qawanted - I'll retest this to be sure. Blocked by bug 765418 to be able to test this.

(In reply to Jason Smith [:jsmith] from comment #13) > (In reply to Jason Smith [:jsmith] from comment #12) > > (In reply to Anant Narayanan [:anant] from comment #11) > > > > 1. I login with the generic account to the public computer > > > > 2. I log into the dashboard with persona #1 > > > > 3. I install an app > > > > 4. I logout of the public computer > > > > 5. Evil person logs with generic account to the public computer > > > > 6. I log into the dashboard with persona #2 > > > > 7. I notice there's other apps are shown on the UI and I delete all of them > > > > > > Ah, okay, this should not occur. Please clarify what you mean by step 4 (I > > > logout of the public computer). If you log out of your Persona, evil person > > > (using persona #2) *should not* be able to delete an app that was installed > > > in persona #1. > > > > > > If they are, then it is a bug, which we should fix (and must block the first > > > release for AITC). Can you re-verify that this is the case? > > > > Sure. Flagging qawanted - I'll retest this to be sure. > > Blocked by bug 765418 to be able to test this. Reword - Blocked by wanting to know why the original expected behavior in bug 761821 is now happening.

Blocked by the results of bug 761045

Somehow this isn't occurring anymore with the more recent nightlys, so resolving as worksforme. I want to know what happened to cause this though...