Closed Bug 1039044 Opened 10 years ago Closed 9 years ago

[B2G][FTE][Geolocation]Users can bypass the FTU by using "everything.me " in "More about your privacy"

Categories

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected)

RESOLVED DUPLICATE of bug 1088461
Tracking Status
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.1 --- affected

People

(Reporter: ekramer, Unassigned)

References

()

Details

(Whiteboard: [273MB-Flame-Support][2.0-exploratory])

Attachments

(1 file)

Attached file FTE_Bypass.txt (deleted) —
Description:
There is a "More about your privacy" link in the Geolocation. Through that link Users can access the jobs section in of "EverythingMe". There are email links in these job postings that take the user to the email app. From here users can access email, settings, and a couple other options on their phone.

Additional Details:
The phone does not behave as intended in this fake state. It does not prompt a lock screen when woken up, and users cannot use most features. The only way out of this state is to Restart the device. 

Note:
This issue reproduces in all memory settings for Flame.

Prerequisite: 
1. Sign into wifi during the FTE

Repro Steps:
1) Update a Flame to 20140711000201
2) In FTE sign into a wifi access point
3) Enter "More about your privacy" in the "Geolocation" tab
4) Enter "everything.me"
5) Press on the "Jobs" section on the top of the "EverythingMe" page
6) Enter any job
7) Scroll down to the bottom of the page
8) Click on the email address provided for applying to the job (jobs@everything.me)
9) Select "OK" in the email confirmation page


Actual:
Users now have basic access to their device, without going through the full FTE. Lock bar is not active when device is awoken. Only way out of this state is to Restart the device. 


Expected:
Users cannot get out of the FTU artificially. 

Environmental Variables:
Device: Flame 2.0
Build ID: 20140711000201
Gaia: 18c44a1bc31b374ba00a069904465a8d07971a60
Gecko: f880dae4fdbe
Version: 32.0a2 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Repro frequency: 100%
See attached: video clip ( http://youtu.be/KyQMF9aA-QA ) and logcat
This issue DOES reproduce on Flame 2.1. Flame 2.0, Flame 1.4, Buri 2.1, Buri 2.0, and Buri 1.4

Note:
This issue reproduces on 512 and 273 memory settings for Flame.

Flame Master
BuildID: 20140711040202
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
Version: 33.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Flame 1.4
BuildID: 20140711000202
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Buri Master
BuildID: 20140711035913
Gaia: c47094a26c87ba71a3da4bae54febd0da21f3393
Gecko: 1b1296d00330
Version: 33.0a1 (Master) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Buri 2.0
BuildID: 20140711045612
Gaia: e1aa5fcc3e1ee2dde9dd935efb1d660c09cf64ff
Gecko: db356a82a908
Version: 32.0a2 (2.0) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 1.4
BuildID: 20140711000202
Gaia: e273c1f52ed7187e4e0b2d66ed5718f0f20c6eeb
Gecko: 896fa800b72d
Version: 30.0 (1.4) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0


Actual Results: 
Users now have basic access to their device, without going through the full FTE. Lock bar is not active when device is awoken. Only way out of this state is to Restart the device.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
I cannot reproduce this issue on the Flame 2.0(273mb). Sending to QA Wanted.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
I was also UNABLE to get this to happen in 273mb because the Email app simply will not load at step 8 no matter how many times you tap on an email link or long tap on the link. 

I am able to repro in 512mb though.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: croesch
Builds attempted on with 273mb

Environmental Variables:
Device: Flame 2.0
BuildID: 20140711211412
Gaia: ca022f811bcbbda0f89086094a9e92bb220fea18
Gecko: b3f6dbd37993
Version: 32.0a2 (2.0) 
Firmware Version: v122

and

Environmental Variables:
Device: Flame 2.0
BuildID: 20140717085706
Gaia: 9977a02ea62ba96425a1cc4d1bfb54a909f68905
Gecko: cc563253a046
Version: 32.0a2 (2.0) 
Firmware Version: v122
It seems that this bug should focus on 512 memory, and that being in 273 memory creates variable results that will block reproduction of this bug by apps being prevented from opeining.

not nomming as a blocker - it seems that these STRs are a bit complex for the average user to encounter.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Duping against bug 1088461, which we'll use as the bug to address these kinds of 'escape/bypass' the FTU via the browser
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: