Another little bit of history: we discussed having a 'slider' when you set
up Sync, either per-account or per-datatype:
* I prioritize recovery over security: keep my data if I reset my password
(use kA)
* I prioritize security over recovery (use kB)
* I prioritize security over convenience (use "
>
> Maybe we could build an escrow service that's still in control of the user,
> for example by splitting the recovery key using shamir's secret sharing and
> assigning each part to a recovery step, with a threshold of 3 to
> reconstruct
> the recovery key.
>
> That's hard to do in practice, but s
>
> Under the hood there would be a bunch of shamir's secret sharing and key
> wrapping palaver to actually make things go.
>
You mean like wrapping the user's kB with their own kA (prove ownership of
your account) plus your friend's kB (prove non-resetness of their account)?
Yeah, that's a dance,
My suspicion is that non-tech users do one of these things:
1. Blame themselves if they can't remember the answers. They remember going
through the process… gosh darn my bad memory, I'm just not good with
computers.2. Get the answers right (at least after trying different
capitalization), becaus
>
> Great discussion. The worry I have with any stored key file is that I
> suspect many of the users resetting their passwords no longer have the old
> hardware. Their old one died. They bougt a new one. Signed in to their
> cloud accounts, and treated Firefox like any other cloud-based account.
>
The original goal I was pushing for, many years ago, was for the FxA device
list to be canonical: it shouldn't be as vulnerable to bugs, duplicates, TTLs,
and stale records as anything a particular identity-attached service stores.
When you kick a device out of your account, its Sync tabs record
I think it's worth outlining some properties of the system in this possible new
world.
Some ideas/questions for discussion:
- The old email address never becomes available for registration again. That
is, email -> FxA user never changes from one user to another.- Can multiple
email addresses be
>
> > - The old email address never becomes available for registration again.
>
> That is, email -> FxA user never changes from one user to another.
>
> We could certainly do this, but it's not clear to me what value it would
> deliver or what it would guard against.
>
My reasoning: devices (and p
Bear in mind that we have 'declined' in meta/global, which is intended to
support exactly this scenario.
A user signing up on Android or iOS can upload a meta/global without "payments"
(or whatever), but it also won't be in 'declined'.
Desktop can use that hook — a locally supported engine that
>
> It's not obvious to me when that "appropriate time" would be though; do
>> users who miss seeing the option during signup have to discover it by going
>> into their sync preferences, or are we considering some sort of in-product
>> messaging to advertise it?
>
>
> I believe the intention is tha
>
> To me, it’s a little weird to see autofill in one of my sync options but I
> cannot find anywhere to use it on my phone. If we prefer to go for this
> proposal, could we at least inform users that autofill only available in
> desktop (for now)?
>
I'm pretty sure I've seen one of rfeeley's mock
>
> * New engines are landed with pref defaulted to disabled.
>
This is a great time to point at Bug 1322428, which would go a long way
towards broadening our funnel.
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/de
Let's try dev-fxacct for this question.
-R
On Sun, Jun 25, 2017 at 10:34 AM, Chris Tybur wrote:
> Gabriel:
>
> Thanks for the suggestion. I was hoping to avoid having to incorporate an
> entirely new way of doing the authentication, if possible.
>
> I should also mention that what I had working
IIRC, Sync itself still has upgrade-required messaging — if we send a
200/404/513 with soft-eol or hard-eol, the device should tell the user that
they need to upgrade to continue syncing.
It might be worth flipping that to soft-eol for the pre-45 population —
which we can identify via UA — and see
As we briefly discussed some months ago, this will cause Sync devices to
collide: you'll have two profiles that both believe they're FxA device
12345 and Sync client abcdef.
Avoiding this should be possible by allocating a new Sync client ID,
forcing the clients collection to need a sync (lastSync
I see https://bugzilla.mozilla.org/show_bug.cgi?id=1419505 already exists
for this, so this mail might just be a broader headsup!
On Mon, Feb 5, 2018 at 3:04 PM, Richard Newman wrote:
> As we briefly discussed some months ago, this will cause Sync devices to
> collide: you'll have t
> Chris, can you clarify whether Android would behave any differently to
> Desktop in this scenario?
Some noodling from my perspective:
We only support a single Firefox Account at present, just as with desktop.
There's no in-Gecko support for FxA at all -- it's all Java -- but I would be
very s
> What even is "marketplace" on android? Is it web content that we need
> to expose the identity to via a DOM API? Is it a privileged app that
> can talk to the FxA account doohickey on your phone? Both, or neither?
Right now it's web content that triggers the download of an APK from the APK
s
> I have found one library called "beecrypt"
> (http://beecrypt.sourceforge.net/doxygen/c++/namespaces.html).
> I want to know whether we can use this library to implement FireFox Sync in
> C++.
> It has got similar C++ APIs for crypto and security modules present in Java.
Assuming that it's a f
> Would an add-on approach be viable for Fennec as well?
Nick, Ryan and I have had some conversations around this. I sent a rough UI
proposal to Ryan a few days ago, on which I'm awaiting comments.
An add-on is more feasible on Android than forcing users to modify
about:config, but there are a
> We have a relatively low-cost opportunity [3] to do something aligned with
> our mission; to do something that is squarely aimed at our valuable tech
> wizards user type, many of whom are feeling abandoned by Mozilla's pro-mass
> market decisions. Let's ride the wave of anti-surveillance sent
> That's an interesting idea. It might also be possible to configure Gecko
> (Necko, really) to be as restrictive as the Android stack we use.
There is a stumbling block here that's worth mentioning: the SSL stacks and
certificate stores are separate. An external tool, or Gecko, will necessaril
> I recently reset my Firefox profile. I signed into my FxAccount with my new
> profile, but used a different Device Name. When I use Firefox for Android's
> "send tab to device" feature, I know see both Device Names in my FxAccount's
> list of devices.
>
> How do I delete this old Device Name
Are you planning to evolve this into something that manages identity-attached
services, or is this just a hard-coded SSO-style thing?
For example, will I be able to answer the questions:
• Which services does this user use with her FxA? (Presumably not all of the
ones we offer…)
• Which service
>
> Any amendments or additions to this list?
>
>
One small one. When the user resets their password (and thus kB changes,
and thus any derived OAuth keys change), there should be a well-documented
way for applications to detect this.
The lifespan of a key should probably not be different to that
Thanks, Ryan.
When you're ready, please send this along to some of the broader lists —
I'm thinking task-continuity-dev, whatever the list is for passwords, etc.
— to help set expectations and catch anything we've missed!
On Thu, Dec 18, 2014 at 4:52 PM, Ryan Kelly wrote:
>
>
> Hi All,
>
>
> Chr
>
>
>- One less password: the password you use to sign into FxA, and to
>unlock the vault, is one and the same.
>- Recoverable: should you ever forget your vault password, you can
>recover it via email (on your Mac or 1Password, if you forget your Master
>Password, you’re hosed)
I might suggest using the term "secondary email" for those kinds of
additional email addresses, keeping the term "primary email" for the one we
use now. Facebook does the same.
That leaves the open question raised by your first message, Ryan: can users
change their primary email? I suspect that's
>
> > It might be easier than you think. ESR is the tough case, but most of
> > our active users are on recent versions of Firefox.
>
> My instinct is to be incredibly conservative when breaking behaviour
> that old Firefoxen depend on, but I've never really had to quantify it.
> What should our d
>
> We certainly have the infrastructure to do this: we do something like this
> on every device right now in order to recover the Android Account across SD
> card manipulations. We would want special support to do this across
> devices, and I'm not sure we want to.
>
To go a step beyond Nick's p
>
> * Our new, simplified COPPA input is now the default for all users,
> meaning our signup process should no longer make people feel old.
>
[image: Inline image 1]
___
Dev-fxacct mailing list
Dev-fxacct@mozilla.org
https://mail.mozilla.org/listinfo/dev
>
> Firefox supports neither hi_IN nor pt_PT, only hi and pt.
>
I'm not sure this is a true statement.
Firefox desktop is built for hi-IN, pt-PT, pt-BR. You can grab
single-locale builds for those locales:
http://ftp.mozilla.org/pub/firefox/releases/42.0b9/mac/
The Accept-Language header that
see neither hi-IN nor pt-PT.
>
> Perhaps that's an issue with the en-US build, obviously a discrepancy
> exists somewhere.
>
> Shane
>
>
> On Tue, Nov 3, 2015 at 3:00 PM, Richard Newman
> wrote:
>
>> Firefox supports neither hi_IN nor pt_PT, only hi and pt.
&
Speaking at a very high level: so long as you version the protocol, version
the data format, and strongly define the types in the format (none of the
"sometimes a number, sometimes a number as a string" crap we have in Sync),
I'm happy.
Remember that users don't upgrade clients as often as we'd li
34 matches
Mail list logo
