Constrainable Pattern
The Constrainable pattern allows applications to inspect and adjust the
properties of objects implementing it. It is broken out as a separate set
of definitions so that it can be referred to by other specifications. The
core concept is the Capability, which consists of a constrainable property
of an object and the set of its possible values, which may be specified
either as a range or as an enumeration. For example, a camera might be
capable of framerates (a property) between 20 and 50 frames per second (a
range) and may be able to be positioned (a property) facing towards the
user, away from the user, or to the left or right of the user (an
enumerated set). The application can examine a constrainable property's
supported Capabilities via the getCapabilities() accessor.
The application can select the (range of) values it wants for an
object's Capabilities by means of basic and/or advanced ConstraintSets and
the applyConstraints() method. A ConstraintSet consists of the
names of one or more properties of the object plus the desired value (or a
range of desired values) for each property. Each of those property/value
pairs can be considered to be an individual constraint. For example, the
application may set a ConstraintSet containing two constraints, the first
stating that the framerate of a camera be between 30 and 40 frames per
second (a range) and the second that the camera should be facing the user
(a specific value). How the individual constraints interact depends on
whether and how they are given in the basic Constraint structure, which is
a ConstraintSet with an additional 'advanced' property, or whether they are
in a ConstraintSet in the advanced list. The behavior is as follows: all
'min', 'max', and 'exact' constraints in the basic Constraint structure are
together treated as the 'required' set, and if it is not possible to
satisfy simultaneously all of those individual constraints for the
indicated property names, the User Agent MUST reject the returned promise.
Otherwise, it must apply the required constraints. Next, it will consider
any ConstraintSets given in the 'advanced' list, in the order in which they
are specified, and will try to satisfy/apply each complete ConstraintSet
(i.e., all constraints in the ConstraintSet together), but will skip a
ConstraintSet if and only if it cannot satisfy/apply it in its entirety.
Next, the User Agent MUST attempt to apply, individually, any 'ideal'
constraints or a constraint given as a bare value for the property. Of
these properties, it MUST satisfy the largest number that it can, in any
order. Finally, the User Agent MUST resolve the returned promise.
Any constraint provided via this API will only be considered if the given
constrainable property is supported by the browser. JavaScript
application code is expected to first check, via
getSupportedConstraints(), that all the named properties
that are used are supported by the browser. The reason for this is that
WebIDL drops any unsupported names from the dictionary holding the
constraints, so the browser does not see them and the unsupported names
end up being silently ignored. This will cause confusing programming
errors as the JavaScript code will be setting constraints but the browser
will be ignoring them. Browsers that support (recognize) the name of a
required constraint but cannot satisfy it will generate an error, while
browsers that do not support the constrainable property will not generate
an error.
The following examples may help to understand how constraints work. The
first shows a basic Constraint structure. Three constraints are given, each
of which the User Agent will attempt to satisfy individually. Depending
upon the resolutions available for this camera, it is possible that not all
three constraints can be satisfied at the same time. If so, the User Agent
will satisfy two if it can, or only one if not even two constraints can be
satisfied together. Note that if not all three can be satisfied
simultaneously, it is possible that there is more than one combination of
two constraints that could be satisfied. If so, the User Agent will
choose.
var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["aspectRatio"]) {
// Treat like an error.
}
var constraints =
{
width: 1280,
height: 720,
aspectRatio: 1.5
};
This next example adds a small bit of complexity. The ideal values are
still given for width and height, but this time with minimum requirements
on each as well that must be satisfied. If it cannot satisfy either the
width or height minimum it will reject the promise. Otherwise, it will try
to satisfy the width, height, and aspectRatio target values as well and
then resolve the promise.
var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["aspectRatio"]) {
// Treat like an error.
}
var constraints =
{
width: {min: 640, ideal: 1280},
height: {min: 480, ideal: 720},
aspectRatio: 1.5
};
This example illustrates the full control possible with the Constraints
structure by adding the 'advanced' property. In this case, the User Agent
behaves the same way with respect to the required constraints, but before
attempting to satisfy the ideal values it will process the 'advanced' list.
In this example the 'advanced' list contains two ConstraintSets. The first
specifies width and height constraints, and the second specifies an
aspectRatio constraint. Note that in the advanced list, these bare values
are treated as 'exact' values. This example represents the following: "I
need my video to be at least 640 pixels wide and at least 480 pixels high.
My preference is for precisely 1920x1280, but if you can't give me that,
give me an aspectRatio of 4x3 if at all possible. If even that is not
possible, give me a resolution as close to 1280x720 as possible."
var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["width"] || !supports["height"]) {
// Treat like an error.
}
var constraints =
{
width: {min: 640, ideal: 1280},
height: {min: 480, ideal: 720},
advanced: [{width: 1920, height: 1280},
{aspectRatio: 1.3333333333}]
};
The ordering of advanced ConstraintSets is significant. In the preceding
example it is impossible to satisfy both the 1920x1280 ConstraintSet and
the 4x3 aspect ratio ConstraintSet at the same time. Since the 1920x1280
occurs first in the list, the User Agent will attempt to satisfy it first.
Application authors can therefore implement a backoff strategy by
specifying multiple optional ConstraintSets for the same property. For
example, an application might specify three optional ConstraintSets, the
first asking for a framerate greater than 500, the second asking for a
framerate greater than 400, and the third asking for one greater than 300.
If the User Agent is capable of setting a framerate greater than 500, it
will (and the subsequent two ConstraintSets will be trivially satisfied).
However, if the User Agent cannot set the framerate above 500, it will skip
that ConstraintSet and attempt to set the framerate above 400. If that
fails, it will then try to set it above 300. If the User Agent cannot
satisfy any of the three ConstraintSets, it will set the framerate to any
value it can get. If the developers wanted to insist on 300 as a lower
bound, they could provide that as a 'min' value in the basic ConstraintSet.
In that case, the User Agent would fail altogether if it couldn't get a
value over 300, but would choose a value over 500 if possible, then try for
a value over 400.
Note that, unlike basic constraints, the constraints within a
ConstraintSet in the advanced list must be satisfied together or skipped
together. Thus, {width: 1920, height: 1280} is a request for that specific
resolution, not a request for that width or that height. One can think of
the basic constraints as requesting an or (non-exclusive) of the individual
constraints, while each advanced ConstraintSet is requesting an and of the
individual constraints in the ConstraintSet. An application may inspect the
full set of Constraints currently in effect via the
getConstraints() accessor.
The specific value that the User Agent chooses for a constrainable
property is referred to as a Setting. For example, if the application
applies a ConstraintSet specifying that the framerate must be at least 30
frames per second, and no greater than 40, the Setting can be any
intermediate value, e.g., 32, 35, or 37 frames per second. The application
can query the current settings of the object's constrainable properties via
the getSettings() accessor.
Interface Definition
Due to the limitations of the interface definition language used in
this specification, it is not possible for other interfaces to inherit or
implement ConstrainablePattern. Therefore the WebIDL definitions given
are only templates to be copied. Each interface that wishes to make use
of the functionality defined here will have to provide its own copy of
the WebIDL for the functions and interfaces given here. However it can
refer to the semantics defined here, which will not change. See MediaStreamTrack Interface
Definition for an example of this.
- Capabilities getCapabilities()
-
The getCapabilities() method returns the dictionary of
the names of the constrainable properties that the object
supports.
It is possible that the underlying hardware may not exactly map
to the range defined in the registry entry. Where this is possible,
the entry SHOULD define how to translate and scale the hardware's
setting onto the values defined in the entry. For example, suppose
that a registry entry defines a hypothetical fluxCapacitance
property that ranges from -10 (min) to 10 (max), but there are
common hardware devices that support only values of "off" "medium"
and "full". The registry entry might specify that for such
hardware, the User Agent should map the range value of -10 to
"off", 10 to "full", and 0 to "medium". It might also indicate that
given a ConstraintSet imposing a strict value of 3, the User Agent
should attempt to set the value of "medium" on the hardware,
and that getSettings() should return a
fluxCapacitance of 0, since that is the value defined as
corresponding to "medium".
- Constraints getConstraints()
-
The getConstraints method returns the Constraints that
were the argument to the most recent successful call of
applyConstraints(), maintaining the order in which they
were specified. Note that some of the optional ConstraintSets
returned may not be currently satisfied. To check which
ConstraintSets are currently in effect, the application should use
getSettings.
- Settings getSettings()
-
The getSettings() method returns the current settings
of all the constrainable properties of the object, whether they are
platform defaults or have been set by
applyConstraints(). Note that the actual setting of a
property MUST be a single value.
- Promise<void> applyConstraints()
-
- Constraints constraints
-
A new constraint structure to apply to this object.
The applyConstraints() algorithm for applying
constraints is stated below. Here are some preliminary definitions
that are used in the statement of the algorithm:
We use the term settings dictionary for the set of
values that might be applied as settings to the object.
We define the fitness distance between a settings
dictionary and a constraint set CS as the sum, for
each constraint provided for a constraint name in CS, of
the following values:
-
If the constraint is not supported by the browser, the fitness
distance is 0.
-
If the constraint is required ('min', 'max', or 'exact'), and
the settings dictionary's value for the constraint does
not satisfy the constraint, the fitness distance is positive
infinity.
- If no ideal value is specified, the fitness distance is 0.
- For all positive numeric non-required constraints (such as
height, width, frameRate, aspectRatio, sampleRate and sampleSize),
the fitness distance is the result of the formula
(actual == ideal) ? 0 : |actual -
ideal|/max(|actual|,|ideal|)
- For all string and enum non-required constraints (sourceId,
groupId, facingMode, echoCancellation), the fitness distance is the
result of the formula
(actual == ideal) ? 0 : 1
More definitions:
- We refer to each element of a ConstraintSet (other than the
special term 'advanced') as a 'constraint' since it is intended to
constrain the acceptable settings for the given property from the
full list or range given in the corresponding Capability of the
ConstrainablePattern object to a value that is within the range or
list of values it specifies.
- We refer to the "effective Capability" C of an object O as the
possibly proper subset of the possible values of C (as returned by
getCapabilities) taking into consideration environmental
limitations and/or restrictions placed by other constraints. For
example given a ConstraintSet that constrains the aspectRatio,
height, and width properties, the values assigned to any two of the
properties limit the effective Capability of the third. The set of
effective Capabilities may be platform dependent. For example, on a
resource-limited device it may not be possible to set properties P1
and P2 both to 'high', while on another less limited device, this
may be possible.
- A settings dictionary, which is a set of values for the
constrainable properties of an object O, satisfies ConstraintSet CS
if the fitness distance between the set and CS is less than
infinity.
- A set of ConstraintSets CS1...CSn (n >= 1) can be satisfied
by an object O if it is possible to find a settings dictionary of O
that satisfies CS1...CSn simultaneously.
- To apply a set of ConstraintSets CS1...CSn to object O is to
choose such a sequence of values that satisfy CS1...CSn and assign
them as the settings for the properties of O.
We define the SelectSettings algorithm as follows:
- Each constraint specifies one or
more values (or a range of values) for its property. A property MAY
appear more than once in the list of 'advanced' ConstraintSets. If
an empty object or list has been given as the value for a
constraint, it MUST be interpreted as if the constraint were not
specified (in other words, an empty constraint == no constraint).
Note that unknown properties are discarded by WebIDL, which
means that unknown/unsupported required constraints will silently
disappear. To avoid this being a surprise, application authors
are expected to first use the
getSupportedConstraints() method as shown in the
Examples below.
- Let object be the
ConstrainablePattern object on which this
algorithm is applied. Let copy be an unconstrained copy
of object (i.e., copy should behave as if it
were object with all ConstraintSets removed.)
-
For every possible settings dictionary of
copy compute its fitness distance, treating bare
values of properties as ideal values. Let
candidates be the set of settings dictionaries for which the
fitness distance is finite.
-
If candidates is empty, return
undefined as the result of the function.
- Iterate over the 'advanced' ConstraintSets in
newConstraints in the order in which they were
specified. For each ConstraintSet:
-
compute the fitness distance between it and each settings
dictionary in candidates, treating bare values of
properties as exact.
-
If the fitness distance is finite for one or more settings
dictionaries in candidates, keep those settings
dictionaries in candidates, discarding others.
If the fitness distance is infinite for all settings
dictionaries in candidates, ignore this
ConstraintSet.
-
Select one settings dictionary from the list of possible
settings, and return this as the result of the
SelectSettings() algorithm. The UA SHOULD use the
one with the smallest fitness distance, as
calculated in step 3.
When applyConstraints is called, the User Agent MUST
run the following steps:
-
Let p be a new promise.
-
Let newContraints be the argument to this
function.
-
Run the following steps in parallel:
-
Let successfulSettings be the result of running
the SelectSettings algorithm with
newConstraints as the constraint set.
-
If successfulSettings is
undefined,
let failedConstraint be any required constraint
whose fitness distance was infinity for all settings
dictionaries examined while executing
the SelectSettings algorithm,
let message be
either undefined or an informative
human-readable message, and reject p with
a new
OverconstrainedError created by
calling
OverconstrainedError(failedConstraint,
message). The
existingConstraints remain in effect in
this case.
- In a single operation, remove
existingConstraints from object, apply
newConstraints, and apply
successfulSettings as the current settings.
- Finally, resolve p. From this point on until
applyConstraints() is called successfully again,
getConstraints() must
return the newConstraints that were passed as an
argument to this call.
-
Return p.
Any implementation that has the same result as the algorithm
above is an allowed implementation. For instance, the
implementation may choose to keep track of the maximum and minimum
values for a setting that are OK under the constraints considered,
rather than keeping track of all possible values for the
setting.
When picking a settings dictionary, the UA can use any
information available to it. Examples of such information may be
whether the selection is done as part of device selection in
getUserMedia, whether the energy usage of the camera varies between
the settings dictionaries, or whether using a settings dictionary
will cause the device driver to apply resampling.
The User Agent MAY choose new settings for the constrainable
properties of the object at any time. When it does so it MUST attempt
to satisfy the current Constraints, in the manner described in the
algorithm above.
- attribute EventHandler onoverconstrained
-
This event handler, of type
overconstrained, is
executed when the User Agent is no longer able to satisfy the
requiredConstraints from the currently valid Constraints.
When executed, the event handler is passed an
OverconstrainedErrorEvent as parameter, which
references an
OverconstrainedError whose
constraint attribute is set to one of the
requiredConstraints that can no longer be satisfied. The
message attribute of
the OverconstrainedError SHOULD contain a
string that is useful for debugging. The conditions under
which this error might occur are platform and
application-specific. For example, the user might physically
manipulate a camera in a way that makes it impossible to
provide a resolution that satisfies the constraints. The
User Agent MAY take other actions as a result of the
overconstrained situation.
An example of Constraints that could be passed into
applyConstraints() or returned as a value of
constraints is below. It uses the properties defined
in the Track property registry.
var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["facingMode"]) {
// Treat like an error.
}
var constraints = {
width: {
min: 640
},
height: {
min: 480
},
advanced: [{
width: 650
}, {
width: {
min: 650
}
}, {
frameRate: 60
}, {
width: {
max: 800
}
}, {
facingMode: "user"
}]
};
Here is another example, specifically for a video track where I must
have a particular camera and have separate preferences for the width and
height:
var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["deviceId"]) {
// Treat like an error.
}
var constraints = {
deviceId: {exact: "20983-20o198-109283-098-09812"},
advanced: [{
width: {
min: 800,
max: 1200
}
}, {
height: {
min: 600
}
}]
};
And here's one for an audio track:
var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["deviceId"] || !supports["volume"]) {
// Treat like an error.
}
var constraints = {
advanced: [{
deviceId: "64815-wi3c89-1839dk-x82-392aa"
}, {
volume: 0.5
}]
};
Here's an example of use of ideal:
var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["aspectRatio"] || !supports["facingMode"]) {
// Treat like an error.
}
var gotten = navigator.mediaDevices.getUserMedia({
video: {
width: {min: 320, ideal: 1280, max: 1920},
height: {min: 240, ideal: 720, max: 1080},
framerate: 30, // Shorthand for ideal.
// facingMode: "environment" would be optional.
facingMode: {exact: "environment"}
}});
Here's an example of "I want 720p, but I can accept up to 1080p and
down to VGA.":
var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["width"] || !supports["height"]) {
// Treat like an error.
}
var gotten = navigator.mediaDevices.getUserMedia({video: {
width: {min: 640, ideal: 1280, max: 1920},
height: {min: 480, ideal: 720, max: 1080},
}});
Here's an example of "I want a front-facing camera and it must be
VGA.":
var supports = navigator.mediaDevices.getSupportedConstraints();
if(!supports["width"] || !supports["height"] || !supports["facingMode"]) {
// Treat like an error.
}
var gotten = navigator.mediaDevices.getUserMedia({video: {
facingMode: {exact: "user"},
width: {exact: 640},
height: {exact: 480}
}});
The Property Registry
There is a single IANA registry that defines
the constrainable properties of all objects that implement the
Constrainable pattern. The registry entries MUST contain the name of each
property along with its set of legal values. The registry entries for
MediaStreamTrack are defined below.
The syntax for the specification of the set of legal values depends on
the type of the values. In addition to the standard atomic types
(boolean, long, double, DOMString), legal values include lists of any of
the atomic types, plus min-max ranges, as defined below.
List values MUST be interpreted as disjunctions. For example, if a
property 'facingMode' for a camera is defined as having legal values
["left", "right", "user", "environment"], this means that 'facingMode'
can have the values "left", "right", "environment", and "user". Similarly
Constraints restricting 'facingMode' to ["user", "left", "right"]
would mean that the User Agent should select a camera (or point the
camera, if that is possible) so that "facingMode" is either "user",
"left", or "right". This Constraint would thus request that the camera
not be facing away from the user, but would allow the User Agent to allow
the user to choose other directions.
- double max
-
The maximum legal value of this property.
- double min
-
The minimum value of this Property.
- double exact
-
The exact required value for this property.
- double ideal
-
The ideal (target) value for this property.
- long max
-
The maximum legal value of this property.
- long min
-
The minimum value of this property.
- long exact
-
The exact required value for this property.
- long ideal
-
The ideal (target) value for this property.
- boolean exact
-
The exact required value for this property.
- boolean ideal
-
The ideal (target) value for this property.
- (DOMString or sequence<DOMString>) exact
-
The exact required value for this property.
- (DOMString or sequence<DOMString>) ideal
-
The ideal (target) value for this property.
Capabilities
Capabilities is a dictionary containing one or more
key-value pairs, where each key MUST be a constrainable property defined
in the registry, and each value MUST be a subset of the set of values
defined for that property in the registry. The exact syntax of the value
expression depends on the type of the property, and its type is as
defined in the Values column of the registry. The Capabilities dictionary
specifies the subset of the constrainable properties and values from the
registry that the User Agent supports. Note that a User Agent MAY support
only a subset of the properties that are defined in the registry, and MAY
support a subset of the set values for those properties that it does
support. Note that Capabilities are returned from the User Agent to the
application, and cannot be specified by the application. However, the
application can control the Settings that the User Agent chooses for
constrainable properties by means of Constraints.
An example of a Capabilities dictionary is shown below. This example
is not very realistic in that a browser would actually be required to
support more constrainable properties than just these.
{
frameRate: {
min: 1.0,
max: 60.0
},
facingMode: ["user", "environment"]
}
The next example below points out that capabilities for range values
provide ranges for individual constrainable properties, not combinations.
This is particularly relevant for video width and height, since the
ranges for width and height are reported separately. In the example, if
the User Agent can only provide 640x480 and 800x600 resolutions the
relevant capabilities returned would be:
{
width: {
min: 640,
max: 800
},
height: {
min: 480,
max: 600
},
aspectRatio: {
min: 1.3333333333,
max: 1.3333333333
}
}
Note in the example above that the aspectRatio would make clear that
arbitrary combination of widths and heights are not possible, although it
would still suggest that more than two resolutions were available.
A specification using the Constrainable Pattern should not subclass the
below dictionary, but instead provide its own definition. See
MediaTrackCapabilities for an example.
Settings
Settings is a dictionary containing one or more key-value
pairs. It MUST contain each key returned in
getCapabilities(). There MUST be a single value for each key
and the value MUST be a member of the set defined for that property by
getCapabilities(). The Settings dictionary
contains the actual values that the User Agent has chosen for the
object's constrainable properties. The exact syntax of the value depends
on the type of the property.
A conforming User Agent MUST support all the constrainable properties
defined in this specification.
An example of a Settings dictionary is shown below. This example is
not very realistic in that a browser would actually be required to
support more constrainable properties than just these.
{
frameRate: 30.0,
facingMode: "user"
}
A specification using the Constrainable Pattern should not subclass the
below dictionary, but instead provide its own definition. See
MediaTrackSettings for an example.
Constraints and ConstraintSet
Due to the limitations of WebIDL, interfaces implementing the
Constrainable Pattern cannot simply subclass Constraints and
ConstraintSet as they are defined here. Instead they must provide their
own definitions that follow this pattern. See MediaTrackConstraints for an example of
this.
Each member of a ConstraintSet corresponds to a constrainable property
and specifies a subset of the property's legal Capability values.
Applying a ConstraintSet instructs the User Agent to restrict the
settings of the corresponding constrainable properties to the specified
values or ranges of values. A given property MAY occur both in the basic
Constraints set and in the advanced ConstraintSets list, and MAY occur at
most once in each ConstraintSet in the advanced list.
- sequence<ConstraintSet> advanced
-
This is the list of ConstraintSets that the User Agent MUST attempt to
satisfy, in order, skipping only those that cannot be satisfied. The
order of these ConstraintSets is significant. In particular, when
they are passed as an argument to applyConstraints, the
User Agent MUST try to satisfy them in the order that is specified.
Thus if optional ConstraintSets C1 and C2 can be satisfied
individually, but not together, then whichever of C1 and C2 is first
in this list will be satisfied, and the other will not. The User
Agent MUST attempt to satisfy all optional ConstraintSets in the
list, even if some cannot be satisfied. Thus, in the preceding
example, if optional constraint C3 is specified after C1 and C2, the
User Agent will attempt to satisfy C3 even though C2 cannot be
satisfied. Note that a given property name may occur only once in
each ConstraintSet but may occur in more than one ConstraintSet.
Privacy and Security Considerations
This section is non-normative; it specifies no new behavior, but instead
summarizes information already present in other parts of the
specification.
This document extends the Web platform with the ability to manage input
devices for media - in this iteration, microphones, and cameras. It also
allows the manipulation of audio output devices (speakers and
headphones).
Without authorization (to the "drive-by web"), it offers the ability to
tell how many devices there are of each class. The identifiers for the
devices are designed to not be useful for a fingerprint that can track the
user between origins, but the number of devices adds to the fingerprint
surface. It recommends to treat the per-origin persistent identifier
deviceId as other persistent storages (e.g. cookies) are
treated.
When authorization is given, this document describes how to get access
to, and use, media data from the devices mentioned. This data may be
sensitive; advice is given that indicators should be supplied to indicate
that devices are in use, but both the nature of authorization and the
indicators of in-use devices are platform decisions.
Authorization may be given on a case-by-case basis, or be persistent. In
the case of a case-by-case authorization, it is important that the user be
able to say "no" in a way that prevents the UI from blocking user
interaction until permission is given - either by offering a way to say a
"persistent NO" or by not using a modal permissions dialog.
It is possible to use constraints so that the failure of a getUserMedia
call will return information about devices on the system without prompting
the user, which increases the surface available for fingerprinting. The
User Agent should consider limiting the rate at which failed getUserMedia
calls are allowed in order to limit this additional surface.
In the case of persistent authorization, it is important that it is easy
to find the list of granted permissions and revoke permissions that the
user wishes to revoke.
Once permission has been granted, the User Agent should make two things
readily apparent to the user:
- That the page has access to the devices for which permission is
given
- Whether or not any of the devices are presently recording ("on air")
indicator
Developers of sites with persistent permissions should be careful that
these permissions not be abused.
In particular, they should not make it possible to automatically send
audio or video streams from authorized media devices to an end point that
a third party can select.
Indeed, if a site offered URLs such as
https://webrtc.example.org/?call=user that would
automatically set up calls and transmit audio/video to
user, it would be open for instance to the
following abuse:
Users who have granted permanent permissions to
https://webrtc.example.org/ could be tricked to send their
audio/video streams to an attacker EvilSpy by following a
link or being redirected to
https://webrtc.example.org/?user=EvilSpy.
