Re: [whatwg] Password managers ignoring autocomplete='off' harming security
On Thu, Oct 2, 2014 at 3:12 AM, Dan Poltawski d...@moodle.com wrote: The most basic case of autocompleting on the same site is the one which is most problematic for us. A traditional username/password to login to the site with autocomplete enabled and functioning as expected - but then after the user has logged in, they do something on a page with one of these (i'll now call) masked fields, and without them noticing - that field is autocompleted with their login password. Previously we could prevent that behaviour by disabling autocomplete on these fields. Note a more traditional example of this which might affect more sites is something like a 'create new user' form where the password would be erroneously set to the password of the user who is creating the accounts. https://html.spec.whatwg.org/multipage/forms.html#autofill has some ways of managing autofill. I'm not sure how much of it is implemented. From that it seems you could use autocomplete=new-password, although if that works as advertized it would have the problem Daniel Cheng mentioned, so perhaps it's only used as heuristic. -- https://annevankesteren.nl/
Re: [whatwg] Password managers ignoring autocomplete='off' harming security
On 2 October 2014 05:15, Daniel Cheng dch...@google.com wrote: Doesn't adding this new input type defeat the whole point of ignoring autocomplete=off? Now sites that want to disable password managers will just use this for their password field, and we're back to square one. Right and at what point does this end? If for our situation we're forced to create our own masking solution which doesn't use a password input, isn't a logical extension that some of these sites which been trying to prevent password managers filling actual password fields will just use this technique too? On a slight tangent, as an avid 1password user I appreciate this functionality of password managers to complete irrespective of what the field says. But I disable the ability of the password manager to auto-fill without my explicit input because I faced this kind of issue. Perhaps the UX of auto-filling these fields could be considered in a different way - all of these problem areas are on pages where the user clearly knows they don't need their password filling in *any* of the fields on the form so if made clear to them, wouldn't consent to it. Dan On Wed, Oct 1, 2014 at 12:19 PM, Dan Poltawski d...@moodle.com wrote: Hi All, Over the past few months all the browser vendors have moved towards ignoring autocomplete=off with password fields. I understand the rationale behind this, but in our software project this has lead to the frustrating situation where we seem to have no good option to deal with this and the change is actively harming the security of our users. To outline the situation in broad terms: * We have shared secrets on the page which we protect against shoulder surfing by using the password element with autocomplete=off * The password managers are now all auto-filling these fields with passwords on the same domain and in many cases without the user even noticing (optional fields they wouldn't look at) * The passwords then get stored in our shared-secret fields clear text and available to all their peers * This can then be used for privilege escalation etc It seems like our only option is avoid use of password field at all and invent our own 'fake' password field to protect our users passwords from being exposed. That seems like a really disappointing solution. (Apologies in advance if this is completely off-list, I saw some threads leading to this list and it wasn't clear to me if this sort of discussion was acceptable). cheers, Dan
Re: [whatwg] Adding a property to navigator for getting device model
On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote: On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. Isn't Cordova experience feedback a bit out of scope if usually developers do UA sniffing on the server side? It seems that such a feature would mostly benefit web sites that already entirely live on the client side and might be more inclined to do feature detection. -- Mounir
[whatwg] Proposal: Wake Lock API
Can I suggest the following approach to wake lock interface:
1. User agent provides an interface to documents such that a document loaded
into the browsing context can indicate whether it wishes to keep the device
awake. Each browsing context has an independent state of this flag.
2. User agent manages global wake lock state considering the following
circumstances:
* Whether the wake lock is currently applicable to some browsing context.
This means that there is at least one browsing context that is not blurred and
has wake lock flag set.
* Whether the wake lock is currently permitted by the state of the
operating system (there is sufficient battery charge etc.)
User agent must observe the state of these conditions, acquiring the wake lock
when they both become true and releasing the lock when one or both of them
become false.
3. User agent has a global flag observable by each browsing context which
indicates whether the global lock is currently held.
4. User agent recognizes some form of document identity (such as URL not
including the fragment identifier) and resets context's wake lock flag when
this identity changes.
The idea behind this is that as the global wake lock is shared between all
browsing contexts (and thus not exclusively owned by any of them) and
furthermore it is subject to conditions out of their control such as context
being blurred or device having insufficient battery charge, it is undesirable
that web applications handle acquisition/release (and failure of these
operations) of the global wake lock themselves, rather, they should set wake
lock preference and user agent should manage the global wake lock for them.
Also, web applications should be able to observe the state of the global wake
lock if they wish to take any special actions when the global wake lock is not
actually set.
An implementation can e.g. look like this:
```
partial interface Document {
// an application can set this flag to true to request wake lock or false
to cancel request
// this attribute is per-context
attribute boolean keepAwake;
}
partial interface Navigator {
// an application can observe this attribute to be notified of the actual
global lock status
// this attribute has the same value for all browsing contexts
[observable] readonly attribute boolean awakeLock;
}
```
Any comments are highly appreciated.
Kind regards,
Andrey Logvinov
Re: [whatwg] Adding a property to navigator for getting device model
On Thu, Oct 2, 2014 at 3:57 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote: On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. Isn't Cordova experience feedback a bit out of scope if usually developers do UA sniffing on the server side? It seems that such a feature would mostly benefit web sites that already entirely live on the client side and might be more inclined to do feature detection. If feature detection covered all the use cases, then why would the Cordova module be so popular? / Jonas
Re: [whatwg] Adding a property to navigator for getting device model
On Fri, 3 Oct 2014, at 04:39, Jonas Sicking wrote: On Thu, Oct 2, 2014 at 3:57 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote: On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. Isn't Cordova experience feedback a bit out of scope if usually developers do UA sniffing on the server side? It seems that such a feature would mostly benefit web sites that already entirely live on the client side and might be more inclined to do feature detection. If feature detection covered all the use cases, then why would the Cordova module be so popular? I would love to know actually. Silvia, do you have any insights? -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
On 3 Oct 2014 04:45, Mounir Lamouri mou...@lamouri.fr wrote: On Fri, 3 Oct 2014, at 04:39, Jonas Sicking wrote: On Thu, Oct 2, 2014 at 3:57 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 19:43, Jonas Sicking wrote: On Wed, Oct 1, 2014 at 2:27 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 1 Oct 2014, at 15:01, Jonas Sicking wrote: On Tue, Sep 30, 2014 at 4:40 AM, Mounir Lamouri mou...@lamouri.fr wrote: On Wed, 24 Sep 2014, at 11:54, Jonas Sicking wrote: Thoughts? Do you have any data that makes you think that those websites would stop using UA sniffing but start using navigator.deviceModel if they had that property available? I know that the Cordova module for exposing this information is one of the most popular Cordova modules, so that's a pretty good indication. But I don't have data directly from websites. When you were pointing that websites currently do UA sniffing is it on the client side of the server side? I'd imagine UA sniffing happens more often on the server side, though I suspect it varies with the reason why people do it. But the Cordova API is client side, so there's definitely desire to have it there too. Isn't Cordova experience feedback a bit out of scope if usually developers do UA sniffing on the server side? It seems that such a feature would mostly benefit web sites that already entirely live on the client side and might be more inclined to do feature detection. If feature detection covered all the use cases, then why would the Cordova module be so popular? I would love to know actually. Silvia, do you have any insights? I've not used it - maybe others have some insights. Best Regards, Silvia.
Re: [whatwg] Notifications: making requestPermission() return a promise
My previous replies to this thread have been about more general issues
regarding promises and exceptions where I felt the need to jump in. Now, about
the actual specific case at hand...
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Anne van
Kesteren
Otherwise I would never expect this promise to be rejected as the user
declining notifications is not exceptional.
I think this is a judgment call. The definition of exceptional is always a
bit tricky. Really it comes down to, should the developer always handle this
case or not?
For example, failures like a file being unreadable can be considered
exceptional, since often a developer doesn't want to handle such failures, but
instead wants to put a big try {} block around a bunch of logic, and if any of
it failed, say something went wrong.
I also maintain that this is partially in how the function is named. For
example, if your function is called `writeToFile()` or
`acquireNotificationPermission()`, it can be considered exceptional for it to
fail.
To illustrate this, let's work in a world with only-sync calls, since that
reduces peoples confusion about this new promises concept and what's
appropriate there. The developer will likely include such calls in a sequence
of operations, one after the other, and expect none of them to fail:
```js
acquireNotificationPermission();
var data = prepareNotificationData();
showNotification(data);
removeFromNotificationQueue(data);
```
in this example, any failures in any of these steps will bubble up to
window.onerror, and get sent to telemetry. That seems OK, and in-line with the
intent of the code.
Whereas, if the function is named `userAllowsNotifications()`, it is much
clearer that you would do
```js
var canNotify = userAllowsNotifications();
if (canNotify) {
var data = prepareNotificationData();
showNotification(data);
removeFromNotificationQueue(data);
}
```
So to me, the question comes down to: do we want to design our APIs around the
model of `acquireNotificationPermission()`, where the developer codes as if
getting permission is an expected normal thing? Or do we want to code them
around the model of `userAllowsNotifications()`, where the developer is
explicitly asking a question?
To answer some contentions that the latter style would force duplicate error
handling with promises: it would not. Very similar to sync code, you would write
```js
userAllowsNotifications().then(canNotify = {
if (canNotify) {
var data = prepareNotificationData();
showNotification(data);
removeFromNotificationQueue(data);
}
});
```
and any other errors (e.g. programming errors, like if someone had typo'd
prepareNotificationData()) would flow up to the developer tools, and eventually
to window.onerror or similar once we get that specced [1]. You would not write
an explicit `.catch(...)` to handle such failures.
(And yes, only Firefox's developer tools correctly show such errors; Chrome is
embarrassingly behind in that regard.)
---
Bringing this back to requestPermission() and notifications: honestly, the name
doesn't help me much in deciding which programming model we want. It could go
either way.
So we should make a choice, as to whether we want developers to assume they
will always get permission (in which case it should reject upon permission not
being granted), or whether we want developers to ask the API whether they were
granted permission (in which case it should give back a boolean fulfillment
value or similar).
[1]: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0024.html
Re: [whatwg] Adding a property to navigator for getting device model
On Fri, 3 Oct 2014, at 05:50, Silvia Pfeiffer wrote: I've not used it - maybe others have some insights. Sorry about that. I misread your previous messages and presumed that you were related to the Cordova project. -- Mounir
Re: [whatwg] Adding a property to navigator for getting device model
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Maybe you missed my initial message : I am a contributor [IPMC] to the Apache DeviceMap Project. [http://incubator.apache.org/devicemap/] DeviceMap does expert UA-sniffing both client and server-side. Apache Cordova on the other hand is a mobile development framework which uses HTML5/CSS/Javascript and via plug-ins allows access to device features not or not consistently accessible [yet] via HTML5. The whole is packaged in a wrapper targeting a specific platform [iOS, Android,...]. So, no 'UA-sniffing' going on there to format content, but HTML5/CSS and javascript running inside a container which via the abstraction of a WebView and plug-ins allows access to things like accelerometer, camera, address-book etc. If you are interested in the intricacies of UA-sniffing, client and server-side, the use-cases, the esoterica etc I'll gladly contribute what I can. Regards, eberhard speer jr. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJULiUDAAoJEOxywXcFLKYc/BYH/RsrgBLLQHcgMfoEp2mU8bKW u5Hrgb1mEIXNp3GO41JW4dX7J9rxTBYlrwMOnznLq2GwM7awiWBVPYvL4cgokAvY xc3lesplBbNONCNq5xNPWHfDHTfxewjyOSPEnH9M/VyFEVsafxRKbMqUdlBLV44c Cmp27o8NDwKih/NQGYEzIfvCfv9l3jR95BpCpGQefq+NdVu4M+PHPnI04VMA3SYZ k2Yl/M0iBIzID3mhLUivTm2xO0OrP6ZqJBXXdpi1FrPzCk9e/I7ahtzJA8V1OwQM O0KsTwf3zlvLOr75SVhlCdOf4/tWs2/zbu7/KSjLSZZLfdsdNPeMnd6rcSo8j2o= =SMaM -END PGP SIGNATURE-
