blink-dev@ intent thread triage report

628 views
Skip to first unread message

Ken Buchanan

unread,
Jan 16, 2017, 12:42:13 AM1/16/17
to security-dev
Triaged 2017-01-01 to 2017-01-13 inclusive, (up to #990 in https://bit.ly/blinkintents):

Intent thread triage was overlooked during the first week of the month, and I was sick for the first half of my week, so the queue was getting pretty loaded. This isn't nearly as bad as the Security Sheriff rotation, though, so a couple of extra coffees on Friday morning and I got this.


This one landed on January 3, two days after the intent was sent. Jochen engaged on the thread at the time, asking about referrer/origin headers on the prefetch request. He noted that there is a slight difference with link prefetch than with regular navigation in the headers that go in the request for subresources, but this is not blocking. The difference also applies to the HTML LINK element.

Adding color management for content in canvas elements improves color fidelity on HDR displays. Not really any concerns here, and I flipped the security launch flag to NA. It occurs to me that this might add another axis for sneaky client fingerprinting, but that reminds of the scene from the Adventures of Baron Munchausen where Venus is given a new diamond and she responds with thanks before tossing it on top of her big pile of diamonds.

We already know about this one, good luck moving it forward!

This API allows pages that are playing media to do two things:
1. Associate metadata with the media that is available to the platform, so that e.g. you can see title track and album artwork on a device lockscreen as you do playing music from native apps, and
2. Allow the page to consume media controls such as from headset buttons, keyboard media buttons, etc.
The Intent to Implement was about a year and a half ago, and it has changed since then. Even though those don't sound like high risk pieces of UI, I think this warrants security and privacy review for the sake of the UX changes. It is unclear to me whether this would meet the bar for needing user permission. I flagged the launch bug accordingly.

This just maximizes the screen space used by fullscreen videos being played in Chrome on Android. I don't think there were any concerns with this, but palmer@ flipped the flag to Launch-Security:Yes last month, so we're good in any case. (Also, mkwst@ noted no issues with the I2I thread.)

estark@'s work. Good stuff.

This is a useful display attribute value to allow an element to create a new block formatting context. Layout detail, no security implications that I can see.

This causes timestamps to be applied to chunks of recorded media. No security risk.

This is removing the AudioContext argument from the AudioBuffer constructor, which complies to a spec change. No security risk.

jochen@ has been following the development of this, so I would defer to him. The launch bug was recently marked as needing security review, but that may have already been looked at (via a comment by hablich@). Does anybody know if this is correct? It might be fine to flip the launch bit here.

Support for attributes in the PointerEvent spec, mainly pertain to stylus. No security risk. #ICantBelieveStylusIsComingBack

Layout enhancement, so that devs can set layout margins that automatically take writing mode, direction and orientation into account. No security risk.

WebUSB is starting another origin trial in M57. This has had security oversight over time and the security bit was flipped last March, so no new concerns.

Implements a getter method required by spec. No security risk.

falken@ has asked for a security review hear because he wants to do an origin trial in M57. mkwst@ was cc'd on it, although would this normally have gone to jww@? In any case, it doesn't look especially risky to me, but warrants a look by somebody who is more familiar with service workers.

Security improvement, no action required.

Pretty sure this is fine.

Jochen Eisinger

unread,
Jan 16, 2017, 3:17:34 AM1/16/17
to Ken Buchanan, security-dev
I indeed looked at this in the past. There are two parts: the WebAssembly object and structured cloning of wasm modules. The former does introduce new risks, you could look at it as a new input format for an existing compiler / VM technology stack.

About the latter there's still ongoing discussion, but afaik this intent to ship does not include structure cloning.

Mounir Lamouri

unread,
Jan 16, 2017, 6:45:20 AM1/16/17
to Ken Buchanan, security-dev, zqz...@chromium.org
On Mon, 16 Jan 2017, at 05:42, Ken Buchanan wrote:
> Intent to Ship: MediaSession API
> <https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/xIpJ_303phw/6PoGcPIGFQAJ>
>
> This API allows pages that are playing media to do two things:
> 1. Associate metadata with the media that is available to the platform,
> so
> that e.g. you can see title track and album artwork on a device
> lockscreen
> as you do playing music from native apps, and
> 2. Allow the page to consume media controls such as from headset buttons,
> keyboard media buttons, etc.
> The Intent to Implement was about a year and a half ago, and it has
> changed
> since then. Even though those don't sound like high risk pieces of UI, I
> think this warrants security and privacy review for the sake of the UX
> changes. It is unclear to me whether this would meet the bar for needing
> user permission. I flagged the launch bug accordingly.

+zqzhang@ FYI

To give more information on this, we had security/privacy review when
the media notification launched a while back (12-18 months?). The media
notification is already customised using `document.title`and the website
favicons. As for as the metadata customisation is concerned, the API
mostly allows website to have better control over this so a music
website doesn't have to change its favicon to the album art in order for
Chrome to pick up the right data. I would assume that having a better
way to do something that was already doable should not be a
security/privacy concern. The actions are not included in there, though.
Happy to follow-up in the launch bug but because they are usually
private, I wanted to make sure the main point was public.

Also, for those interested, the specification has a "Securtity & Privacy
considerations" section.

-- Mounir

a...@google.com

unread,
Jan 23, 2017, 1:00:15 PM1/23/17
to Security-dev
[Replying on an existing thread as per estark@'s request]

Light week, with only a handful of intents to implement; most of the entries were deprecate+remove (which I ignored).

Triaged 2017-01-14 to 2017-01-23 inclusive, (up to #1005 in https://bit.ly/blinkintents):

Implement: Dangling markup mitigations [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/rOs6YRyBEpw/D3pzVwGJAgAJ] - Mike's work to lock down vectors used for exfiltration in the presence of markup injection (e.g. to make stealing of CSP nonces harder). Security-positive.

Implement and ship: MediaStreamTrack.getSettings() [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/wJwVSo52Dno/z5Tg0JmVAgAJ] - returns information about a MediaStreamTrack (source of video/audio from a user device). One interesting property is the facing mode which says where the media source is facing relation to the user; however, given that this is behind the permission and the user had to allow media capture this doesn't look troubling.

Implement and ship: Browser Shortcuts in Fullscreen [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/wlRDnLbyVlk/uuByF-a1AgAJ] - sensitive key combos (e.g. Ctrl+T, Ctrl+W) will now be intercept-able by the web app when in fullscreen mode. Some incremental risk of phishing if user is accustomed to opening new tabs viai shortcuts and will forget they are in fullscreen mode, but overall okay.

Implement and ship: Shoutcast support [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/qS63pYso4P0/FP6xymqNAwAJ]. If you're wondering "what year is this?" then don't worry all that much -- the proposed change is to re-allow previously disabled HTTP/0.9 responses over non-default ports only if they start with a Shoutcast magic string ("ICY"). But the context is worth reading, at least for the entertainment value ;-)

Cheers,
-Artur

David Ross

unread,
Jan 30, 2017, 7:03:09 PM1/30/17
to Security-dev, a...@google.com
Triaged 2017-01-24 to 2017-01-30 inclusive, (up to #1012 in https://bit.ly/blinkintents):

Implement: Background Fetch API [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Ia9_-CVrl1U/oW0riJbHBAAJ]

I sent the following feedback on the blink-dev thread for this feature:


Assuming XSS on a domain, an attacker could queue up downloading that happens on behalf of the victim domain, in the background, even after the user has closed the browser.  Though if UI is always shown then this is probably not all that interesting.


There are a handful of things that likely just need a bit of clarification in the spec:

  • What happens with downloads initiated from incognito mode?  Should they terminate immediately once the incognito session is over?

  • The spec doesn’t mention credentials.  It appears that backgroundFetch.fetch() needs to be called on a request object that has been set up beforehand.  I can imagine that an implementation would likely punt the request to an external downloading process that is longer-lived than the browser itself.

  • On the desktop, does the download stop if the user closes the notification?  As spec’d, it shouldn’t be possible to close the notification and have the download persist in the background.

  • What happens if you clear browsing data while a download is in progress?

  • How is the user aware of ongoing downloads on a mobile browser?

  • What’s the scope of a “tag”?  (Per-origin?  What about protocol scheme?)  I would expect the tag mechanism to obey the SOP.

  • Is CORS respected?

  • Is this mechanism regulated appropriately by CSP?  (E.g.: connect-src)


Implement: Unblocking Scroll when Main Thread Unresponsive [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/CGeXqTudllA/3t72vfXOBAAJ]

The only conceivable worry might be around clickjacking / tapjacking scenarios, though I can’t find anything concrete.

Implement and ship: annotating parts of navigator.credentials with [SecureContext] [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/-E-O9LgsPfM/ExJ7hiY1BQAJ]

Making navigator.credentials invisible in insecure contexts is nothing but goodness.

Implement and ship: color-gamut media query [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/36CcloDrB3E/1wMSNMl9BQAJ]

In theory this could contribute to a “super cookie.” However I do not believe it’s useful to limit programmatic access to basic characteristics of the UA.

Dave

Jochen Eisinger

unread,
Feb 13, 2017, 3:19:46 AM2/13/17
to David Ross, Security-dev, a...@google.com
Triaged 2017-02-06 to 2017-02-12 inclusive (up to #1026 in https://bit.ly/blinkintents):

Implement and ship: Referrer-Policy header for CSS [https://groups.google.com/a/chromium.org/d/msg/blink-dev/YkXg6ZkW2Bs/6aDLAs0qBwAJ]

The best. Totally.

Implement: Providing effective network speed to web servers [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/TS9zT_u2M4k/ydZK5WpTBwAJ]

Provides additional information that could be used to fingerprint clients, or narrow down their physical location (see http://wicg.github.io/netinfo/#privacy-considerations). Maybe it's reasonable to require the information about max bandwidth etc.. to be normalized to some coarse buckets?

Will the headers only be sent via HTTPS?

Deprecate and remove: Support for HTTP over port 9100, 6697, and 631. [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Ttkgd4aPkW0/7Uwd-S16BwAJ]

Trying to address the problem that some services can be tricked into echoing back parts of the request which are then interpreted by the client as valid response headers. We already maintain a list of such known "bad ports". Seems reasonable to add further ports to that list.

Implement and ship: Snapshot iframe allowfullscreen attribute [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/UKChYGBYvSk/dXXdHGyhBwAJ]

no concerns. Aligns behavior with other attributes such as sandbox.


<base> tags are supposed to make dealing with relative URLs easier. Not allowing data: URLs makes sense (and matches what FF does).


Gives workers similar capabilities as the Window, so no new information channels.

Implement and ship: Pause autoplaying muted video when invisible (Android) [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/UtFM-kndhaI/19dqA4klCAAJ]

Seems reasonable.

Deprecate and remove: FileReaderSync in service workers [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/cjWtqRD6iw8/hcxtAeE2CAAJ]

no concerns from security

Implement and ship: UserAgent Stylesheets for Extensions [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7v-v9LT3Ioc/kNWTv69DCAAJ]

Not web-exposed, but also otherwise not concerning from security PoV.

Eduardo' Vela" <Nava>

unread,
Feb 13, 2017, 11:22:03 AM2/13/17
to Security-dev

On Monday, January 16, 2017 at 6:42:13 AM UTC+1, Ken Buchanan wrote:

Jochen Eisinger

unread,
Feb 13, 2017, 11:34:40 AM2/13/17
to Eduardo' Vela" <Nava>, Security-dev

Mike says he'll post the update for them really soon now ™

Emily Stark

unread,
Feb 20, 2017, 1:36:27 AM2/20/17
to Jochen Eisinger, Eduardo' Vela <Nava>, Security-dev
Triaged 2017-02-13 through 2017-02-17 inclusive (up through #1036 in https://bit.ly/blinkintents).

Changes these getters to return null instead of throwing. No security concerns. (Bug does not look like a launch bug, no security bit to flip.)

Sounds like it does what it says on the tin. No security concerns. We could all do with less rage. (Bug does not look like a launch bug, no security bit to flip.)

Changes addRange() to do nothing if there already is a selection. No security concerns. (Bug does not look like a launch bug, no security bit to flip.)

Adds an attribute to mark DOM nodes as inert, which means that they aren't tabbable, aren't searched through Find-in-Page, and are hidden from assistive technology. No security concerns. Flipped security bit.

Exposes the client's media decoding capabilities for the server to streamline a site's media selection. Overall the Media Capabilities API seems like it could be a new fingerprinting vector, which I guess is not a dealbreaker, but I replied on-thread to suggest adding a Security/Privacy Considerations section to the spec.

Eduardo' Vela" <Nava>

unread,
Feb 24, 2017, 10:09:13 AM2/24/17
to Security-dev
Hi Emily, your summary says 02-13 to 02-17 inclusive (up through #1036) but there are no notes for Indexed DB 2.0 for example.

It seems you intended to say you already worked on this, but I'm not sure, so just confirming?


On Monday, January 16, 2017 at 6:42:13 AM UTC+1, Ken Buchanan wrote:

Emily Stark

unread,
Feb 24, 2017, 11:35:12 AM2/24/17
to Eduardo' Vela <Nava>, Security-dev
Hey Eduardo -- per the instructions at https://sites.google.com/a/chromium.org/dev/blink/intent-security-triage, I only triaged "Intent to Implement" or "Intent to Implement and Ship" threads.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

Eduardo' Vela" <Nava>

unread,
Feb 27, 2017, 6:42:24 AM2/27/17
to Emily Stark, Security-dev
Oh, I see. Intent to Ship is out of scope.. Thanks =)

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Eduardo' Vela" <Nava>

unread,
Feb 27, 2017, 6:46:18 AM2/27/17
to Security-dev
Triaged 2017-02-17 through 2017-02-24 inclusive (up through #1039 in https://bit.ly/blinkintents).

  • CSS Box Alignment shorthands
    • These are just shortcuts for existing CSS properties. Not even something worth updating in CSS/HTML sanitizers. I say ship it!

Ken Buchanan

unread,
Mar 7, 2017, 3:11:16 PM3/7/17
to Security-dev
There doesn't seem to have been a recent email. Was triage done last week?

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

Lucas Garron

unread,
Mar 7, 2017, 9:55:05 PM3/7/17
to Ken Buchanan, Security-dev
Apparently not. Here are the last two weeks, up through line 1051 in  https://bit.ly/blinkintents

Implement and ship: native media controls customization API

No security concerns. Just some customization for the media controls presented to a user (to discourage everyone implementing their own media controls).


Implement and ship: Temporarily stop permission requests after 3 dismissals

No security concerns. This can only deny powerful features to websites (based on strictly local data).


Implement: Unprefix -webkit-line-break behind 'test' runtime flag

No new security concerns. Behind a flag, affects text layout (possibly only East Asian scripts?)


Implement and ship: DeviceOrientationEvent and DeviceMotionEvent constructors

No concerns. Adds synthetic event constructors for testing, but doesn’t expose more device features to the web.


Implement and ship: SVGImageElement as CanvasImageSource

No (new) security concerns. Leaking history/cross-origin data through canvas is a known problem, but the implementers make it clear that tainting is handled like for other image sources.


Implement: `sample` property for CSP reports.

Some privacy concerns, but samples are limited to 40 chars and mkwst@ himself is running the show.


Implement and ship: RTCPeerConnection icegatheringstatechange event

No security concerns. From what I can tell, this doesn’t introduce any new API surface (assuming correct implementation), only a convenience event for WebRTC peer connections. In case you – like me – are wondering what “ICE” means here, it stands for Interactive Connectivity Establishment.



»Lucas



To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Ken Buchanan

unread,
Mar 13, 2017, 12:55:17 AM3/13/17
to Security-dev
Intents update covering to 2017-03-12 through line 1055 in https://bit.ly/blinkintents.

Intent to Implement and Ship: wakeup-based background timer throttling
No concerns. This would modify the throttling mechanism for timers set by background tabs.

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.


Artur Janc

unread,
Mar 20, 2017, 10:54:43 AM3/20/17
to Ken Buchanan, Security-dev
Intents update covering up to 2017-03-20 (through line 1060 in https://bit.ly/blinkintents).

Intent to implement and ship: Screen.colorDepth and Screen.pixelDepth can return other value than 24
Allowing the UA to report the true color depth of the display to help sites decide whether to send HDR video (for example). Minor incremental fingerprinting potential (an extra bit) by passing more information from the environment, but this can probably already be inferred from other display characteristics.

Pretty much what the title says -- currently mouse events aren't sent to disabled form elements, which seems awkward. No security impact.

Intent to implement: Accessibility Object Model
A fairly complex proposal to expose a programmatic API for a native "accessibility tree" (a DOM-like structure to capture a11y-relevant elements), helping build accessibility-friendly components. After reading the explainer my main reservation is that this seems like a lot of complexity and I'm worried about subtle issues in the interaction between the AOM and the DOM, but I didn't see any obvious problems with the current proposal.

Cheers,
-Artur
 


--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev+unsubscribe@chromium.org.

David Ross

unread,
Mar 24, 2017, 5:35:11 PM3/24/17
to Security-dev, ke...@google.com, a...@google.com

Triaged 2017-03-20 to 2017-03-24 inclusive, (up to #1069 in https://bit.ly/blinkintents):


Implement and Ship: Partial RTCRtpReceiver and RTCRtpContributingSource [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/0aTOUhS0wCY/cr-FSkpVCAAJ]


After some discussion with hbos@ & team I don’t see this adds any new design-level concerns for WebRTC.  There may be opportunity for fuzzing coverage here and additional security focus on WebRTC overall though.


Ship: `script-sample` property for CSP reports [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/XlcpobBfJOI/8WYpiyk0CQAJ]


(Intent to Ship is understood to be out of scope but this week I did them anyway.)

From Twitter, there’s the suggestion that reporting UI might not properly deal with XSS payloads in script-sample.  I think the burden there is clearly on the reporting UI to do the right thing.  I’ve been refactoring a large site to include CSP, which wouldn’t have been possible without data provided from FF’s implementation of this feature.


The opt-in, inline-limited approach is a good way to address previous concerns about cross-origin data leakage.  I have to assume that the implementation will properly encode samples for use in JSON.


Implement: CSS conic-gradient() [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/-z66SwKdklc/5t-NBchECQAJ]


No issues.


Implement and Ship: Frames timing function [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/j7l8_DjMsVE/OiOo5zNwCQAJ]


No issues.


Implement and Ship: CSS Selectors Level 4: :focus-within pseudo-class [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/V3RNBhQelSg/twVPZYOACQAJ]


Two things that come to mind on anything like this:

  • It’s worth considering the potential for interesting behavior assuming injection of CSS on a page is possible.  I don’t see that focus-within creates a problem.

  • Can this somehow better enable clickjacking?  I don’t see a possibility here.


This could be considered to enable a sort of “scriptless event handler.”  Though I think it’s unlikely that there’s a new attack scenario here that wouldn’t otherwise exist with CSS.


Ship: Feature Policy V1 [https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/uKO1CwiY3ts/62vV7xmaCQAJ]


I called out the following issues / questions on the blink-dev@ intent to ship thread:


If the camera is blocked in a frame, that frame can simply navigate the top level away to use the camera.  I’m not sure what the spec’s opinion on this is.


The spec mentions web workers but I’m not sure if / how policy would apply to service workers.


Can this header be supplied via a META tag?  This would enable documents on file:// URLs to set Feature Policy.


Presumably there will be test cases to ensure that, for example, “allow” policy specified in a frame doesn’t somehow override “deny” policy specified by its parent.


Reporting (ala CSP) could be helpful with deployment, so it’s something to consider, though maybe not a priority.


It's worth filling out the Privacy and Security section of the spec.  There's enough here that's security relevant that it would be worthwhile time spent.


Dave
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.


--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev...@chromium.org.

Mike West

unread,
Apr 6, 2017, 9:27:34 AM4/6/17
to Security-dev
Triaged 2017-03-25 to 2017-04-02 inclusive, (#1070 - #1091 in https://bit.ly/blinkintents):

21 intents... was it the end of the quarter or something? :)

# Intent to Implement: JavaScript image decode() API.

The only change here is to give developers more insight into image decoding, but does not present fundamentally new ability (as the developer can do the same by just inserting the image into the DOM). No concerns.

# Intent to Ship: Image Capture API

This is locked behind the same permission prompt as `getUserMedia`, and locked to secure contexts. It offers developers a little more control over the way images are captured, but not an arbitrary level of control. This seems like only a marginal increase in attack surface over the existing WebRTC APIs.


This was my intent, so... I'm biased, but it seems security-positive.

# Intent to implement and ship: Add request identifier to PaymentDetailsInit

This is a developer-controlled string, but so is everything else in this part of the API. No security concerns.


Can we remove it with a user gesture too? :) No security concerns with locking this down.

# Intent to Experiment: GetInstalledRelatedApps API

This API has some privacy implication, as it allows a developer to determine whether one of their applications is installed. From a security perspective, however, the potential for mischief is reduced by requiring a secure context, and by locking the available applications to those that explicitly list the requesting origin on the one hand, and those origins that list the requested application on the other. Opting in from both sites removes the abuse scenarios I've thought about.


This is a minor privacy win, and brings interop with Safari. No security concerns.

# Intent to Deprecate and Remove: SVGTests.requiredFeatures attribute

No concerns.

# Intent to Implement: CSS transform-box

No concerns.

# Intent to Implement and Ship: CSP hash expressions matching external scripts.

This was also my intent, so... I'm still biased, but it seems security-positive.

# Intent to Ship: InputEvent

No security concerns. It gives a developer access to a user's input, but they'd already have that access if they can execute JavaScript on the origin.

# Intent to Implement and Ship: DataTransfer constructor

No security concerns about the constructor, but as Jochen notes on the intent thread, the larger clipboard API that this supports needs independent review before launch.

# Intent to Continue Experimenting: WebVR

No new concerns that aren't already captured in https://w3c.github.io/webvr/spec/1.1/#security.


The offline functionality is based on MHTML, which strips the document of its origin, and prevents JavaScript execution. I've reviewed a few of the CLs going by for its impact on CSP, and I'm comfortable with the security properties we're ensuring here.

We'll have more to talk about with the packaging mechanisms coming down the pike, but I see this change as relatively benign.


This adds some timestamps to WebGLTexture, which seems fine in itself. I'm not super enthusiastic about implementing things without a spec, with the apparent goal of being used internally for Google properties to test things, but if it helps us towards the goal of specifying something other browsers will implement (and we remove it in a reasonable timeframe), great.

# Intent to Deprecate and Remove: Headers.prototype.getAll()

No concerns.

# Intent to Ship: APNG Support

No new concerns. The library has solid fuzzer coverage, and security signed off on the launch bug.

# Intent to Implement and Ship: Require user gesture for beforeunload dialogs

No security concerns. Less non-interactive `beforeunload` is better `beforeunload`.

# Intent to Ship: Writeable streams

I have no concerns with the API itself, but this feature is interesting from a security standpoint because it's written as a V8 Extra, which means that the security considerations listed in https://docs.google.com/document/d/1AT5-T0aHGp7Lt29vPWFr2-qG8r3l9CByyvKwEuA8Ec0/edit#heading=h.32abkvzeioyz apply. Skimming through https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/streams/WritableStream.js, it looks like those pitfalls are consistently avoided, and I trust both the author and reviewers have done the right thing.


No concerns.

# Intent to Deprecate and Remove: Non-standard APIs in Document

This intent drops `document.webkitHidden` and `document.webkitVisibilityState`. The usage looks pretty high, but assuming we dropped them, I don't think there would be negative security implications.

PhistucK

unread,
Apr 6, 2017, 5:16:46 PM4/6/17
to Mike West, Security-dev
See my comment inline.


☆PhistucK

On Thu, Apr 6, 2017 at 4:27 PM, Mike West <mk...@chromium.org> wrote:
Triaged 2017-03-25 to 2017-04-02 inclusive, (#1070 - #1091 in https://bit.ly/blinkintents):

21 intents... was it the end of the quarter or something? :)

# Intent to Implement: JavaScript image decode() API.

The only change here is to give developers more insight into image decoding, but does not present fundamentally new ability (as the developer can do the same by just inserting the image into the DOM). No concerns.

# Intent to Ship: Image Capture API

This is locked behind the same permission prompt as `getUserMedia`, and locked to secure contexts. It offers developers a little more control over the way images are captured, but not an arbitrary level of control. This seems like only a marginal increase in attack surface over the existing WebRTC APIs.


This was my intent, so... I'm biased, but it seems security-positive.

# Intent to implement and ship: Add request identifier to PaymentDetailsInit

This is a developer-controlled string, but so is everything else in this part of the API. No security concerns.


Can we remove it with a user gesture too? :) No security concerns with locking this down.

# Intent to Experiment: GetInstalledRelatedApps API

This API has some privacy implication, as it allows a developer to determine whether one of their applications is installed. From a security perspective, however, the potential for mischief is reduced by requiring a secure context, and by locking the available applications to those that explicitly list the requesting origin on the one hand, and those origins that list the requested application on the other. Opting in from both sites removes the abuse scenarios I've thought about.

​Would it also be ​fine by you in the desktop context, or is it only fine by you in the mobile context?
I mean, yes, on desktop, the application can install a local server on an agreed port that returns a response when called by the web application. But the user can generally shut it down.
In this case, the user cannot escape this query. This information is simply revealed to the web application.
I would not want the websites I use to know whether I have their applications without asking me. They, for example, may push me into using them instead of using the website, but I prefer the website. They do not disturb users without their applications, so I am in an inferior position as a result of this API.
(Perhaps I should put this piece of feedback on the original thread, though?)

 

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

Mike West

unread,
Apr 7, 2017, 8:22:26 AM4/7/17
to PhistucK, Security-dev
On Thu, Apr 6, 2017 at 11:16 PM, PhistucK <phis...@gmail.com> wrote:
# Intent to Experiment: GetInstalledRelatedApps API

This API has some privacy implication, as it allows a developer to determine whether one of their applications is installed. From a security perspective, however, the potential for mischief is reduced by requiring a secure context, and by locking the available applications to those that explicitly list the requesting origin on the one hand, and those origins that list the requested application on the other. Opting in from both sites removes the abuse scenarios I've thought about.

​Would it also be ​fine by you in the desktop context, or is it only fine by you in the mobile context?
I mean, yes, on desktop, the application can install a local server on an agreed port that returns a response when called by the web application. But the user can generally shut it down.
In this case, the user cannot escape this query. This information is simply revealed to the web application.
I would not want the websites I use to know whether I have their applications without asking me. They, for example, may push me into using them instead of using the website, but I prefer the website. They do not disturb users without their applications, so I am in an inferior position as a result of this API.

For context, the main goal for this triage report is to try to catch security implications early enough to influence the design of a feature, not to pass judgement on whether or not a feature is a good idea for either the platform or the user. That's a product decision at the end of the day, which is a different kind of question.

From a security perspective, this doesn't seem to add new surface area, given that an origin that owns both a site and an app can already create communication channels between them on Android (via Chrome Custom Tabs in one direction, and intents in the other), and desktop (the app runs a local server (or, in the worst case, injects into Chrome directly)). I agree with you that there are privacy implications to making it trivial to determine installation status. The claim is that the user benefit outweighs. I think it's pretty reasonable to give those kinds of claims broad leeway for experimentation as opposed to shipping, but again, those are product decisions.
 
(Perhaps I should put this piece of feedback on the original thread, though?)

That's probably a better way to give feedback to both the API developers and Blink's owners for consideration when the intent to experiment turns into an intent to ship.

Thanks!

-mike 

Jochen Eisinger

unread,
Apr 10, 2017, 9:26:33 AM4/10/17
to pal...@chromium.org, Security-dev
Triaged 2017-04-03 to 2017-04-09 inclusive, (#1092 - #1097 in https://bit.ly/blinkintents):


Exposing additional information about supported codecs. Appears to be in line with exposing more information about the bits per pixel of the display.


Not an intent to implement technically, but the spec has security & privacy considerations, and reserve() fails if it's not invoked in a secure context, so that's good.


Same as above.


no concerns.

# Intent to Ship: CSSOM View smooth scroll API

no concerns.

# Intent to Ship: SharedArrayBuffer

Internal security review was requested (+pa...@chromium.org is doing it afaik). The main concern is about introducing a high-res timer in the platform, but there appear to be no alternatives if we want sufficiently fast shared memory for asm.js/WebAssembly.

Emily Stark

unread,
Apr 14, 2017, 6:35:53 PM4/14/17
to Jochen Eisinger, Chris Palmer, Security-dev
Triaged 2017-04-10 to 2017-04-14 inclusive (#1098-1109 in https://bit.ly/blinkintents)

This seems to not be adding any new functionality, just a syntax change, so no security concerns.

This seems a tad concerning on the privacy side, so I suggested adding a Privacy/Security Considerations to the explainer. There's already an issue on file for correlating cross-browsing-context, cross-origin browsing activity. Other than that I'm not sure it's much worse than any old fingerprinting vector.

I dunno, this MIke West character seems a little sketchy but he seems to think this is security-positive.

No concerns.

Fingerprinting concerns are addressed by limiting the granularity. Discussed in more detail in http://httpwg.org/http-extensions/client-hints.html#security-considerations and https://github.com/spanicker/device-ram#security--privacy

No concerns

No concerns

--

Ken Buchanan

unread,
Apr 24, 2017, 10:46:52 AM4/24/17
to Emily Stark, Jochen Eisinger, Chris Palmer, Security-dev

Lucas Garron

unread,
May 1, 2017, 5:23:38 PM5/1/17
to Ken Buchanan, Emily Stark, Jochen Eisinger, Chris Palmer, Security-dev
Triaged up to #1116-1116 (ending 2017-05-01):

No security concerns. No change in exposed surface, just code org. Also, Mike and Jochen already LGTMed. ;-)

No security concerns.

No security concerns.
(I tried thinking of a crazy use case where an app's assumptions can combine with this to form a security bug. Can't think of anything unless the app's event handling is already fragile.)

»Lucas

--
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.


Eduardo' Vela" <Nava>

unread,
May 8, 2017, 5:46:09 PM5/8/17
to Lucas Garron, Ken Buchanan, Emily Stark, Jochen Eisinger, Chris Palmer, Security-dev
Hello!

Triaged up to 1126! May 5.
  • RTCRtpSender
    • Adds an interface to discover information about your remote peer. I think it has some interesting fingerprinting consequences, as now you would be able to know more information about your peer (eg, which codecs does your peer's browser support?). Beyond that, there is some information exposed about the DTLS (like the remote certificates), which might be interesting if it was possible to fool the browser into speaking DTLS to a port that isn't trying to talk WebRTC (eg, in an intranet), but otherwise this seems OK.
  • messageerror event and event handlers
    • meh, they will add a new event for when arraybuffers fail to be transfered via postMessage. Since all transferable objects are origin agnostic/capabilities I don't see how one could create any type of infoleak with this.
  • : Add Client.type
    • meh, service workers could already figure this out before, and even if they couldn't this seems ok.
  • throw on invalid URLs passed to window.open()
    • uber meh. might be an interesting way to interrupt execution of javascript unexpectedly, but it looks super low risk.
  • PushSubscription.expirationTime
    • meh, just exposing the expiration time of a push subscription.
  • PushManager.supportedContentEncodings
  • RTCCertificate.getFingerprints()
    • Same concerns to the RTCRtpSender above.

David Ross

unread,
May 15, 2017, 12:58:51 AM5/15/17
to Security-dev, lga...@google.com, ke...@google.com, est...@google.com, joc...@chromium.org, pal...@chromium.org

Triaged 2017-05-08 to 2017-05-12 inclusive, (up to and including #1134 in https://bit.ly/blinkintents):

 

Implement and Ship: draft-ietf-webpush-encryption-08

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/SX9_nZ1NHy8/g-PQuoUiBAAJ]

 

A move to support the latest version of the encryption scheme used by webpush.  I have no concerns but ping’d some of our crypto folks.  Quan Nguyen pointed out:

“I would suggest adding a section about verifying peer's public key is on the private key's curve in ECDH protocol. Without this check, for the curve that they use P-256, it would allow attacker to extract the private key.”

Peter Beverloo has relayed this to the folks working on the spec.

  

Implement and Ship: The password property of PasswordCredential

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nT51eE7fWn4/8HBF1NtqBAAJ]

 

“allows developers to directly read the password from JavaScript” Well that sounds bad. =) However in discussion on the thread, Dominic Battre pointed out that in Chrome it’s already the case that script can trigger password disclosure into the DOM in an automated way.  Thus, allowing the password property wouldn’t enable anything that isn’t already possible.

 

I recommended a note in the spec to discourage implementation of the password property in browsers with more conservative password managers.  (See the thread.)  But in Chrome at least, it looks like the password property is reasonable to implement given the password will already be accessible in the DOM, by design.

 

Implement and Ship: `mediation` enum argument to `CredentialsContainer::get()` in Credential Manager API

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/veCKBk1NguM/ctyHrdVWAwAJ]

 

The user mediation concept is security relevant but I don’t see anything here that’s worrisome.  It would be good to have tests to ensure, for example, setting mediation to “silent” doesn’t enable inappropriate credential access.


PhistucK

unread,
May 16, 2017, 12:18:00 PM5/16/17
to Eduardo' Vela <Nava>, Lucas Garron, Ken Buchanan, Emily Stark, Jochen Eisinger, Chris Palmer, Security-dev

On Tue, May 9, 2017 at 12:45 AM, 'Eduardo' Vela" <Nava>' via Security-dev <securi...@chromium.org> wrote:
I think it has some interesting fingerprinting consequences, as now you would be able to know more information about your peer (eg, which codecs does your peer's browser support?).

I believe this stems from the SDP string anyway (the browser does not get more information from the peer itself), so it does not add anything, it just makes it easier to read this information rather than parsing SDP strings.​
(But correct me if I am wrong).

Same regarding the getFingerprints ("Currently we create (or retrieve from indexdb) a certificate, set it on a peerconnection and create a dummy offer,  we then parse the resulting SDP to get the certificate's fingerprint." by Tim Panton).


☆PhistucK

Mike West

unread,
May 23, 2017, 5:58:34 AM5/23/17
to Security-dev
Triaged 2017-05-14 to 2017-05-21 inclusive, (up to and including #1142 in https://bit.ly/blinkintents):

# Implement and Ship: `CredentialsContainer::create`

No concerns. This just provides an asynchronous, Promise-based mechanism for doing something that's current synchronous.

# Implement and Ship: CSS Box Alignment

No concerns.


No concerns. Just moving an existing piece of functionality from one place to another in the API.


I agree with the privacy questions raised in the thread, and I think I agree with the general feeling that this data is already obtainable in one way or another by interested servers. Given that, I don't think it adds surface area from a security perspective. Still, I've flagged the launch bug for internal privacy folks who should really weigh in.


From a security perspective, the Quota APIs in general are scary. I know there's ongoing work on the existing APIs to reduce the ability to read sizes cross-origin, and I encourage that effort to continue, as it's an important hole to address.

But, as jsbell@ notes, it's an existing hole in an existing API that Blink already ships. From that perspective, this new way of reaching the same underlying data doesn't make things any worse than they already are.


No concerns. Removing surface area is almost always good.


No concerns. This is just a rename of an existing method.


From a security perspective, I don't think this adds notable surface area in itself. I'm not actually sure it's a good idea, though. I don't understand what sites intend to do in response to seeing this boolean, nor do I understand why an automated client would send it. I've commented on the thread.

-mike


Jochen Eisinger

unread,
May 29, 2017, 11:18:13 AM5/29/17
to Security-dev
Triaged 2017-05-22 to 2017-05-28 inclusive, (up to and including #1152 in https://bit.ly/blinkintents):


Why do ppl put those URLs on their pages in the first place?

# Intent to Ship: Wasm Response API

It allows for strongly binding a Wasm Module to an origin. I like it.


No concerns


Since the embedee has to opt-in to a policy at least as strict as the embedder would like to see, or is otherwise not loaded at all, I don't see a security concern here.

# Intent to Ship: WebUSB

navigator.usb is only exposed to secure contexts - good.

The spec doesn't appear to require user mediation to access a device, it just says that the UA may do that. I wonder whether the spec should be more prescriptive here. Similarly, it doesn't seem to restrict the kinds of devices a site can talk to, so it may be possible to access a device with less user interaction / different UX via WebUSB compared to the regular API.

I asked those questions on the intent to ship, let's see what happens

# Intent to Implement: WebRTC Frame Logging API

The linked spec doesn't have security & privacy considerations. Asked for them.


Same as intent to implement (#1090) - no concerns

# Intent to Deprecate and remove: AppBannerPromptResult interface

Changing interface to Dictionary - no concerns

# Intent to Implement: CSP: `report-to` directive

The fetching API using requests with mode "cors", so that's good. Seems strictly better than the old report-uri based approach.

# Intent to Implement and Ship: Mandatory `as` value for link rel preload

No concerns. This seems strictly better than the status quo.

Emily Stark

unread,
Jun 2, 2017, 6:58:15 PM6/2/17
to Security-dev
Triaged 2017-05-29 through 2017-06-02 (up to and including #1157 in https://bit.ly/blinkintents)

Light week for the web platform this week...

Allows enumeration of the attributes available for an element, seems fine.

Extremely security-positive, yay.

Eduardo' Vela" <Nava>

unread,
Jun 9, 2017, 2:20:47 AM6/9/17
to Emily Stark, Security-dev
Triaged up to #1161 (inclusive) since estark@'s report below.

Loading Dispatcher v0 - background tab throttling ( https://groups.google.com/a/chromium.org/d/msg/blink-dev/iS0Szd-GD7E/n27gJoBpCAAJ ) - this seems to be introducing an information leak. Will take a closer look next week.

Referrer policies 'same-origin', 'strict-origin', 'strict-origin-when-cross-origin' ( https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/TgtPUowSWuU/Y-Sn2oRsCAAJ ) - add more referrer options to chrome. I don't know why we call everything strict now a days :-(, but I guess the ship has sailed. That said this strict-origin seems to be useful in that it strips referrers when dropping to HTTP even when a referrer policy exists. I didn't realize before that we were sending referrers to http when a policy was present (since we don't when there isn't one).

onappinstalled and onbeforeinstallprompt event attributes ( https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/_kZHUBQHSXo/1PkuGAOiCAAJ ) - just adding attributes to hook into events that already exist. I guess the only thing that might matter is stuff like XSS filters that don't filter on.* but who cares about that anymore?


Ken Buchanan

unread,
Jun 19, 2017, 9:00:44 AM6/19/17
to Eduardo' Vela <Nava>, Emily Stark, Security-dev
Triaged 2017-06-09 through 2017-06-16 (up to and including #1168 in https://bit.ly/blinkintents):

Only one I2I thread this week, Deprecation Reports, Reporting Observer. estark@ responded to it, noting existing security concerns with the Reporting API (specifically, the need to implement CORS preflights).

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

David Ross

unread,
Jul 5, 2017, 2:20:18 PM7/5/17
to Security-dev, e...@google.com, est...@chromium.org, ke...@google.com

Triaged 2017-06-26 to 2017-06-30 inclusive, (up to and including row 1188 in https://bit.ly/blinkintents):


There are a couple of new or custom intent types that I’ve seen lately (Intent to Experiment, Intent to Change).  It might be good to clarify the triage process (https://www.chromium.org/blink/intent-security-triage) to specify if these should be reviewed during triage.


Implement and Ship: URLSearchParams.sort()

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/U0p_jFYpgss/st46sTGjAAAJ]


Good to see that sorting maintains the relative order between name-value pairs with equal names.  Probably there are some other corner cases to account for in test cases.  For example, querystrings with name/value pairs lacking names: ?=1&=2&foo=bar.  Or invalid URL encoding in the querystring like %Z.  Though probably a bug here would be out of scope for .sort().


Implement and Ship: <data> element

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/IjFvnq8yzy8/n_vYt5oUBQAJ]

This is interesting w.r.t. sanitizers in the same way that data-* attributes are interesting.  Unfortunately it’s not clear that there’s a good default behavior -- sometimes <data> elements should pass, but not in other cases, it’s entirely application dependent.  Similarly, <data> elements could be interesting if they are used by libraries that then enable CSP bypass gadgets.  (ref: https://github.com/google/security-research-pocs/tree/master/script-gadgets)  I don’t see anything needs to happen for this particular intent though.


Implement and Ship: move onwheel IDL attributes from Element to GlobelEventHandlers

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Wa5sdcDrJnA/JsgX8zhlAQAJ]

OK.


Implement: EME Extension - Policy Check

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Okto6s417Q8/5HfUclFqAQAJ]

Exposes a small bit of info about the user agent but I agree with the conclusions in the Privacy Risk section of the Intent writeup.


Implement and ship: beforeprint and afterprint events

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/3B0I0EDKfpk/leSOUkN0AQAJ]

This may make it easier in some sense to print something that doesn’t correspond to what the user actually intended to print.  Though I suspect this isn’t a problem that can be easily avoided in any case.  It also exposes to javascript that the user attempted to print the page, which might be considered as impacting user privacy.  Overall though, the benefits of this feature outweigh the drawbacks.


Implement and ship: <time> element

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/e52E3t3ijHo/eyEaNDt1AQAJ]

OK.


Implement and ship: bilinear interpolation for upscaled images

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/6L_3ZZeuA0M/STPVOjKwAQAJ]

OK.


Experiment: Shape Detection

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/eJnB-5Sg-mQ/uvdWnO2OBQAJ]

Intent to Implement for this one predates the triage rotation.  The spec properly rejects cross-origin face detection.  I would hope / expect this to fail fast so that timing couldn’t be used to detect faces cross-origin.  Any feature like this that exposes low-level hardware functionality is at least a little scary, though in this case the risk seems very limited.


Change: XMLHttpRequest preload matching

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/kfE0RHQrULA/RWD3kmfRAQAJ]

OK.


To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Artur Janc

unread,
Jul 20, 2017, 2:09:07 PM7/20/17
to David Ross, Security-dev, Eduardo Vela Nava, est...@chromium.org, Ken Buchanan
Below are my notes for the intents from my missed rotation last month (before David's week). Sorry for the delay! 

Triaged rows 1169 (6/19) to 1176 (6/23) inclusively.

Intent to Implement: Scroll Anchoring Serialization:
No security impact.

Intent to Ship: Clear-Site-Data header
Generally security- and privacy-positive. A small concern is that programmatic control over the HTTP cache might allow some more reliable attacks to detect the presence of items in the cache. I started a thread with Mike about this and a couple of other things.

Intent to Ship: <script type="module">
This probably warrants a closer look once we see how modules will be used in practice by developers -- generally they don't seem to add sensitive functionality that wouldn't otherwise be available in the platform, nor do they make it easier for developers to make mistakes. IOW no issues at this point.

Intent to Implement and Ship: updateViaCache for service workers
Extra attribute to decide whether to use the cache when updating service workers. No concerns.

Intent to Implement: visibility:collapse for table rows
No security impact.

Intent to Implement: Accept-CH-Lifetime support
I have some concerns about this feature related to both broadcasting fingerprintable information to third parties, and allowing providers of subresources to identify the referring origin even if it sets `Referrer-Policy: no-referrer`. The discussion is in https://github.com/httpwg/http-extensions/issues/372.

Intent to implement and ship: change argument type in URLSearchParams' constructor
Minor implementation change with little effect on the platform. No concerns.

--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev+unsubscribe@chromium.org.

PhistucK

unread,
Jul 21, 2017, 3:10:09 AM7/21/17
to David Ross, Security-dev, Eduardo' Vela <Nava>, Emily Stark, Ken Buchanan
> Probably there are some other corner cases to account for in test cases.  For example, querystrings with name/value pairs lacking names: ?=1&=2&foo=bar.  Or invalid URL encoding in the querystring like %Z.  Though probably a bug here would be out of scope for .sort().

It would be great if you made sure this is noted somewhere actionable (crbug.com or the specification or web platform tests or something).


Thank you.


☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

Jochen Eisinger

unread,
Jul 21, 2017, 5:08:08 AM7/21/17
to PhistucK, David Ross, Security-dev, Eduardo' Vela <Nava>, Emily Stark, Ken Buchanan
Triaged 2017-06-30 to 2017-07-16 inclusive, (up to and including row 1197 in https://bit.ly/blinkintents):

Intent to Implement and Ship: Expose the SyncManager interface to Workers
The interface is already exposed to service workers and windows, so concerns here. The API is also only available to secure contexts. Yay.

Intent to implement: JavaScript module import()
There was a question about allowed content type, and the good news is that we require

Intent to Ship: Expect-CT HTTP header
Some back and forth on CORS, but Emily is totally on top of that.

Intent to Implement: V8 context snapshot
Just a perf improvement, no concerns.

Moving work off of the main thread. No concerns.

Intent to Deprecate and Remove: Presentation API on Insecure Contexts
That's the right direction, no concerns.

Intent to Deprecate and Remove: FTS extension support in WebSQL
No security concern here either.

Reported value is rounded to multiples of 512MB. Should client hints be restricted to HTTPS connections? I asked on the thread.

An invalid string will be "undefined" instead of throwing a syntax error. Shrug, seems fine.

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Emily Stark

unread,
Jul 24, 2017, 3:27:09 PM7/24/17
to Jochen Eisinger, PhistucK, David Ross, Security-dev, Eduardo' Vela <Nava>, Emily Stark, Ken Buchanan
Triaged 2017-07-17 to 2017-07-24 inclusive, up to and including #1205 in https://bit.ly/blinkintents

Syntax change, no privacy or security implications

Does not seem to introduce any significant new API surface; observes information that is already available via Performance interface, and the observer interface is already available for Windows. Privacy considerations are covered by https://www.w3.org/TR/hr-time-2/#privacy-security

Privacy and security considerations are covered well by https://w3c.github.io/hr-time/#privacy-security


To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

Eduardo' Vela" <Nava>

unread,
Jul 31, 2017, 12:17:32 PM7/31/17
to Security-dev
Did 1206 and 1207 July 31 2017.

1206
7/27/2017 Mathias Bynens Ship RegExp `dotAll` mode / `s` flag < LGTM x3 - ECMAScript feature
https://groups.google.com/a/chromium.org/forum#!msg/blink-dev/0uSHjqvgAwQ/CqmFd6KNAwAJ

This makes .* match new lines and such when the s flag is on. Not really that different from status quo.

1207
7/30/2017 Mathias Bynens Ship RegExp lookbehind assertions < LGTM x3 - ECMAScript feature
https://groups.google.com/a/chromium.org/forum#!msg/blink-dev/DKElo3p6n38/PvSV4-KFBAAJ

This enables look behind in regexps for V8. ReDoS and such is the only concern but it's not new. Meh.

Ken Buchanan

unread,
Aug 6, 2017, 9:24:07 PM8/6/17
to security-dev
Triaged 2017-08-01 to 2017-08-06 inclusive, up to and including #1212 in https://bit.ly/blinkintents

Intent to Implement and Ship: Support FLAC in ISO-BMFF with MSE
Here is the launch bug, which is not linked from the intent. The only thing about this is to ensure it has adequate cluster-fuzz coverage.

Intent to Implement: Fix for Accept-Language HTTP Headers
No security concerns.

Intent to Deprecate and Remove: Browser commands should not generate user gestures
This is a security positive intent that is generating a bit of discussion. 

Intent to Implement: Origin Policy
Security positive.

Artur Janc

unread,
Aug 29, 2017, 11:02:20 AM8/29/17
to security-dev
Triaged 2017-08-07 to 2017-08-21 inclusive, up to row #1225 in the sheet (sorry for the delay, hopefully this will get the triage queue back to normal)

Extension of SRI to allow signatures based on Mike's explainer; security-positive with small caveats around replay / version rollback and key management which are well described in the doc.

Reasonable and security-positive, especially after the DNS restrictions on the localhost label start applying.


--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev+unsubscribe@chromium.org.

Jochen Eisinger

unread,
Sep 5, 2017, 8:46:40 AM9/5/17
to Artur Janc, security-dev
Triaged 2017-08-22 to 2017-091-01 inclusive, up to row #1243 in the sheet.

Intent to Implement and Ship: CSS font-variant-east-asian

no concerns

Intent to Implement and Ship: CSS: Support 'q' length unit

no concerns

Intent to Implement and Ship: media preload defaults to metadata

this ends up downloading less, so no concerns

Intent to Implement and Ship: history.index

Exposes where in the local history the current site is. That data was already present before, the accessor just makes it more accessible.

Intent to Ship: Device Memory JS API

Privacy concern from Firefox that the buckets too fine-grained which makes this an unnecessary fingerprinting surface. Pinged the privacy team about this.

Intent to Implement and Ship: Accept-Language Headers language expansion

no concerns (no additional information is revealed, and duplicates are removed which decreases the fingerprint somewhat).


Remove information leak \o/


no concerns

Intent to Implement: Fix Chrome MSE PTS/DTS Compliance

no concerns

Intent to Implement: Offset-based Touch Adjustment

no concerns

Intent to Implement: Incremental Marking in Oilpan

That introduces the possibility of missing write barriers. A technical mitigation in debug mode is in place. Added palmer@ to the thread so he's aware of this.


no concerns


no concerns


no concerns

Intent to Ship: Keyboard lock

Repeated my request for a launch bug to be filed.



To unsubscribe from this group and all its topics, send an email to security-dev...@chromium.org.

Emily Stark

unread,
Sep 10, 2017, 4:53:31 PM9/10/17
to Jochen Eisinger, Artur Janc, security-dev

To unsubscribe from this group and all its topics, send an email to security-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

David Ross

unread,
Sep 26, 2017, 12:08:39 AM9/26/17
to Security-dev, joc...@chromium.org, a...@google.com

Triaged 2017-09-18 to 2017-09-24 inclusive, (up to and including row 1259 in https://bit.ly/blinkintents).


Implement: Trusted Types for DOM Manipulation

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/qbOrXp9g3B8/hziymUnHAQAJ]


Very cool!  I trust Koto, Sebastian, and Mike will get the details right.  It looks like this currently dances around sanitization, which is probably the right way to go.  (It’s likely out-of-scope for this feature to dictate if a FORM element is safe/unsafe markup, for example.) I should probably dust off my old “Safe Node” concept and see how it might work in conjunction with this proposal.  (https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0113.html)


I sent this over to Christoph Kern to take a look too.


Implement and Ship: throw NotSupportedError for unsupported playbackRate

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/a0tguvcZZyk/QJjO8R3WFgAJ]


No issues.


Implement: Gesture Delegation

[https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/e7I1tZAfavU/wjgW9s0EBAAJ]


I commented in the thread:

The security questionnaire should probably cover "GestureJacking."  That is, the case where a malicious outer page uses this feature to affect a victim frame from a different origin.  Right now the feature only seems to regulate autoplay and vibration, so it's no big deal, but in the future maybe more things will rely on activation (?).  Behavior w.r.t. sandboxed and nested frames should probably be considered as well.
Maybe it would be sufficient allow gesture delegation only for same-origin scenarios?

Jeffrey Yasskin pointed me to an ongoing discussion of these sorts of issues: https://github.com/WICG/gesture-delegation/issues/4



Note: I switched weeks with Ken Buchanan who will now be taking the first week of October.


To unsubscribe from this group and all its topics, send an email to security-dev...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Ken Buchanan

unread,
Oct 9, 2017, 12:45:07 AM10/9/17
to David Ross, Security-dev, Jochen Eisinger, Artur Janc
Triaged up to 2017-10-08 inclusive, (up to and including row 1269 in https://bit.ly/blinkintents).

No concerns.

This is an attempt to prevent tab-unders where pages initiate main frame navigations and then open popups. No concerns.

This shouldn't add any risk beyond what already exists for autocomplete on <input> elements, other than possibly some amount of implementation-side risk, since we have occasional bugs relating to <input> autocomplete being too easy to fill.

Not much to say about this one, since Mike has most of the context, and discussion was punted back to https://github.com/w3c/webappsec-csp/pull/247.

Intents to Remove don't strictly need triage, but go Avi!

No concerns. This would add the ability for a web app to ask that subsequent text content be displayed after an image even before the image has finished rendering.

This would enable web content to determine whether the user wants to minimize data transfer quantity (for slow networks, etc). No concerns.

voge...@chromium.org

unread,
Oct 16, 2017, 7:18:43 AM10/16/17
to Security-dev, joc...@chromium.org
Triaged up to 2017-10-14, rows 1269..1275 in https://bit.ly/blinkintents.

Intent to Remove: ImageCapture.setOptions()
No concern.
This looks to have security implications. Thankfully, the right people are already on the thread. I added the following request to the thread:

"Zentaro, have you added tests that verify whether connection groups for NTLMv2 indeed segregate requests with/without credentials and different cookie settings (e.g. 3rd-party cookie blocking)?"


Intent to Implement and Ship: WebAudio: AudioParam Setter is setValueAtTime
No concern.

Intent to Implement: Simple User  [Because: This seems to strictly reduce when JS can run, so I can't see any security concern.]Activation
No immediate concern. This aims to re-work & improve the concept of "user activation", which has security & privacy implications. I've cc:-ed jochen on the intent thread.

No concern. (This looks to be finger-printable, but probably doesn't add any information that isn't already contained in the User-Agent string.)

Intent to Implement: Fetch API: keepalive
No concern.

No concern.

Daniel Vogelheim

unread,
Oct 16, 2017, 9:17:08 AM10/16/17
to Security-dev, Jochen Eisinger
Minor correction: The previous mail had an editing error. The 4th entry is meant to read:

Intent to Implement: Simple User Activation
No immediate concern. This aims to re-work & improve the concept of "user activation", which has security & privacy implications. I've cc:-ed jochen on the intent thread.

Message has been deleted

andy...@google.com

unread,
Oct 23, 2017, 7:03:15 AM10/23/17
to Security-dev, joc...@chromium.org, voge...@google.com
Triaged rows 1276 - 1278 of bit.ly/blinkintents

Last intent date 10/20/2017

Intent to Implement: Slots in a flat tree https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/5s1nbytTL68/SnnummScBAAJ
No Concerns

Intent to implement and ship: import.meta.url
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Hq3cVNto74c/x7tNhmZUBQAJ
No concerns

Jochen Eisinger

unread,
Oct 27, 2017, 7:43:15 AM10/27/17
to andy...@google.com, Security-dev, voge...@google.com
Triaged rows 1279 to 1283 of bit.ly/blinkintents


no concerns


no concerns

Intent to Ship: CSS transform-box

no concerns

Intent to Deprecate and Remove: legacy touch event APIs on desktop devices

removing stuff is great


I asked whether this should be restricted to secure contexts

Emily Stark

unread,
Nov 3, 2017, 8:14:46 PM11/3/17
to Jochen Eisinger, Andy Paicu, Security-dev, Daniel Vogelheim
Triaged rows 1284-1291

Intent to Deprecate and Remove: Public Key Pinning
I have a conflict of interest. :) Security concerns are already discussed in depth in the intent and thread.


--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

Ken Buchanan

unread,
Nov 13, 2017, 12:15:22 AM11/13/17
to Security-dev
Triaged rows 1292-1300 inclusive.

No concerns. Just provides a convenient class for adding a transformation to a data stream.

No concerns. This is a special <link rel="preload"> for modules, which allows omitting credentials with the request, and also proactively fetches further dependencies.

No concerns.

No concerns. This changes the encoding of filenames in <input type="file"> fields when the current encoding can't display characters in the filename. Seems reasonable and matches other browsers.

I don't know very much about WebRTC, but this looks fine based on it being an implementation of a part of the WebRTC spec and the object itself is pretty benign.

This allows scripts to lock access to a resource, similar to a mutex (and is broader than the Atomics object because it affects agents that can't share memory with each other). Since it explicitly should only affect agents that are in the same origin, I don't see any security concerns at the design level.

Daniel Vogelheim

unread,
Nov 24, 2017, 9:15:46 AM11/24/17
to Security-dev
Triaged rows 1301-1306 of bit.ly/blinkintents.
No concerns. The intent would improve security.

No concerns. Since the intent to implement, a spec has been added. I don't see anything security-related.
No concerns. This intent would improve security.
No concerns. This might help finger-printable (user has mouse with >=5 buttons), but I don't think this is terribly relevant here.
No concerns. (WebVTT is apparently some sub-title on video thingy, so technically this looks like an extension of a media codec of sorts. I guess there's always an implementation risk with those, but I can't see anything more.)

No concerns. This intent would improve security.

Andy Paicu

unread,
Dec 11, 2017, 2:48:44 AM12/11/17
to Security-dev
Triaged rows 1306-1313 of https://bit.ly/blinkintents

No concerns, I don't see any security implications in waiting for idle time to sending a low prio queue. 

No concerns, just allowing you to disable some OS processing when retrieving audio 

No concerns, adding some missing fields in an event init constructor

No concerns, it's probably an improvement  in terms of security

Implement and ship HTTP Too Early
No concerns, it helps TLS

Implement and ship CSS Color 4 RGB{A} Syntax
No concerns, different syntax for colors in CSS

Implement :any-link
No concerns, selector already exists it just has a vendor specific prefix 

Regards,
Andy

PhistucK

unread,
Dec 11, 2017, 3:24:48 AM12/11/17
to Andy Paicu, Security-dev
>Implement and ship KeyboardEventInit keyCode, charCode support
>No concerns, adding some missing fields in an event init constructor
This might open an attack vector for web applications, though, because it was not possible up until now. Right?


☆PhistucK

--

Andy Paicu

unread,
Dec 11, 2017, 3:37:15 AM12/11/17
to PhistucK, Security-dev
It seems unlikely to me, more so because it has already been shipped in two other browsers.

But if you have concerns around it, feel free to ask in the thread. 

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Jochen Eisinger

unread,
Dec 18, 2017, 4:25:40 AM12/18/17
to Andy Paicu, PhistucK, Security-dev
Triaged rows 1314-1324 on https://bit.ly/blinkintents


no security issues

Intent to Ship: image decoding attribute

no concerns


no concerns


From my limited understanding of TLS, 1-RTT is less scary than 0-RTT, but seems like our network security folks already looked at it anyways..

Intent to Ship: :any-link

still no concerns


Same as the RGB{A} variant, no concerns


no concerns


no concerns

Intent to Deprecate and Remove: SharedArrayBuffer.isView

no concerns

Intent to Deprecate and Remove: Content Type Sniffing for Worker Scripts

that'd be security positive

Intent to Implement: Unified Touch adjustment

having touch and gesture events targeting the same thing sounds like an improvement

Emily Stark

unread,
Dec 22, 2017, 6:42:20 PM12/22/17
to Jochen Eisinger, Andy Paicu, PhistucK, Security-dev
Triaged rows 1325-1328 on bit.ly/blinkintents

no concerns

no concerns

Seems security-positive by removing cross-origin frames' access to device orientation unless explicitly granted via feature policy. Concerns are already noted in the thread (mostly from Mozilla) about wanting to eventually deprecate these APIs all together (or all together in cross-origin frames) and this seems like a step in that direction.

no concerns

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

Artur Janc

unread,
Jan 8, 2018, 5:32:59 AM1/8/18
to Emily Stark, Jochen Eisinger, Andy Paicu, PhistucK, Security-dev
Triaged bit.ly/blinkintents rows 1329-1334:

Adding more information about the type of requested resource to tell a Service Worker what it's fetching. No concerns.

No concerns.

No concerns.

--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev+unsubscribe@chromium.org.

Daniel Vogelheim

unread,
Jan 15, 2018, 5:29:42 AM1/15/18
to Security-dev, Emily Stark, Jochen Eisinger, Andy Paicu, PhistucK, Artur Janc
I was totally going to do my triage shift for rows 1335+, but bit.ly/blinkintents shows no entries after 1334. So, no concerns about nothing.

How can I check whether whatever thing imports the data into the spreadsheet is still working?

Daniel Vogelheim

unread,
Jan 15, 2018, 5:35:46 AM1/15/18
to Security-dev, Emily Stark, Jochen Eisinger, Andy Paicu, PhistucK, Artur Janc
On Mon, Jan 15, 2018 at 11:29 AM, Daniel Vogelheim <voge...@google.com> wrote:
I was totally going to do my triage shift for rows 1335+, but bit.ly/blinkintents shows no entries after 1334. So, no concerns about nothing.

How can I check whether whatever thing imports the data into the spreadsheet is still working?

There were several new intents last week, so clearly the import thingy is broken. 

Mike West

unread,
Jan 15, 2018, 5:37:40 AM1/15/18
to Daniel Vogelheim, Dru Knox, Security-dev, Emily Stark, Jochen Eisinger, Andy Paicu, PhistucK, Artur Janc
+Dru, who can fix things, I hope? :)

-mike

Jochen Eisinger

unread,
Feb 7, 2018, 6:15:37 AM2/7/18
to Mike West, Daniel Vogelheim, Dru Knox, Security-dev, Emily Stark, Andy Paicu, PhistucK, Artur Janc

Now that the spreadsheet is back up, Mike and I triaged the rows up to row 1370 (2018-02-04)


Intent to Implement: WebRTC Unified Plan SDP

Signaling the SDP format a given browser supports doesn't appear to create any attack surface. No concerns.


Intent to Implement: CSS Layout API

No concerns


Intent to Ship: Async Clipboard API

Ensuring that clipboard access is available only in the active tab prevents some of the earlier concerns about persistent background access from a Worker to a user's clipboard, which seems dangerous. Still, flagging this thread to Enamel, as I think it might have fallen off the table due to personnel changes.


Intent to Implement: window.focus() exits HTML5 fullscreen

Security positive


Intent to Experiment: Extend Origin Trial - Media Capabilities: decoding

Nothing new


Intent to Implement and Ship: Send “input” event on checkbox click.

No concerns


Intent to Implement and Ship: window.focus() exits HTML5 fullscreen

Same as above


Intent to Implement: Permission Delegation

This is an important change to the way permissions work in general. The Enamel team is involved, and supportive, and the hope is that it will give users a better understanding of who they're expressing trust towards, and to whom they're granting permissions. It seems to me to be a step in the right direction, but it's very much worth keeping an eye on it as it evolves due to e.g. TAG feedback.


Intent to Implement and ship: PerformanceObserver takeRecords()

This improves developer ergonomics, but doesn't enable any action that developers couldn't already take. No concerns.


Intent to Deprecate and remove: URL.createObjectURL with MediaStream

This doesn't result in any change in the functionality exposed to developers. It removes one spelling of a feature, and asks developers to use a different spelling. No concerns.


Intent to Implement and ship: Feature Policy control over Synchronous XHR

Synchronous XHR doesn't create independent security issues, and Feature Policy seems like the right way to give developers control over it as a stepping-stone to complete removal. No concerns.


Intent to Implement and ship: Optional catch binding

No concerns


Intent to Experiment: EME Extension - Policy Check

The explainer discusses privacy considerations (https://github.com/WICG/media-capabilities/blob/master/eme-extension-policy-check.md#privacy-considerations) and points out that the fingerprinting surface doesn’t significantly expand.


Intent to Implement: Origin-Signed HTTP Exchanges (Part of Web Packaging)

Yup. There are concerns. The right people are looking into them. We'll expect solid answers before we ship.


Intent to Deprecate and Remove: Extra form data , if "value" attribute is present with non-empty value for <input type=”image”>

No concerns


Intent to Deprecate and Remove: support for position values with 3 parts (excluding background)

No concerns


Intent to Implement and ship: Send “input” Event on activation behavior for radio and file <input> type

No concerns


Intent to Ship: CSS Typed OM

Adding explicit JS types for CSS which currently is done by parsing / generating strings → no new attack surface


Intent to Deprecate and Remove: Support for '#' in data URI body

There's some marginal risk that treating `#` as a fragment in a `data:` URL could result in markup meaning something different than it used to. The risk, however, is mitigated by the fact that the `data:` URL will render in an opaque origin, and by the low usage numbers. Seems reasonable to ship and align with other vendors' behavior: more predictability increases the odds that developers won't shoot themselves in the foot.


Intent to Implement and ship: Unprefix CSS Grid Layout gutter properties

No concerns


Intent to Implement and ship: CSS calc() in media queries

No concerns


Intent to Ship: More spec conformant SendBeacon quota

No concerns


Intent to Implement and ship: make <tr> with transform be a containing block

No concerns


Intent to Experiment: Experiment: Signature-based Resource Loading Restrictions

Similar to the already shipped hash-based variant


Intent to Implement and ship: New CSS Value 'legacy' for the alignment behavior of HTML’s <center> element

No concerns


Intent to Implement: Picture-in-Picture (PiP)

They limit security concerns by restricting the PiP content to an video that is controlled via an HTMLMediaElement. Still have some questions around what happens if you switch tabs or navigate away.


Intent to Deprecate and ship and remove: justify-items: auto

No concerns


Intent to Implement and ship: Support 'x' as a CSS resolution

No concerns


Intent to ship: Create V8 contexts from snapshot by default

No concerns


Intent to Implement and ship: Reading Blob URL for invalid/nonexistent Blob should end with a network error

No concerns


Intent to Implement: Lazily load below-the-fold iframes and images

No concerns


Intent to Implement and ship: performance.memory improvements

This removes data about cross-origin resources, so that’s great


Intent to Implement: Cooperative Scheduling

Security team is already reviewing this.


Intent to Deprecate and remove: Throwing on unimplemented (but valid) CompositeOperation values in WebAnimationsAPI.

No concerns


Intent to Remove: Appcache in non-secure contexts.

Yay!


Intent to Implement: :is()

No concerns


Emily Stark

unread,
Feb 11, 2018, 12:07:58 PM2/11/18
to Jochen Eisinger, Mike West, Daniel Vogelheim, Dru Knox, Security-dev, Andy Paicu, PhistucK, Artur Janc
Triaged up through row #1381 (2018/02/09).

no concerns

It's not clear to me if this is exposing new data to web contents (which might be a persistent identifier and/or fingerprinting risk) or not. I asked on the thread.

I *think* this is the same thing as something I've been discussing with Zach on-and-off for quite a while. There are a number of tricky security UX questions and last I heard we were not going to do a permission prompt because it was going to be too hard to phrase comprehensibly. But the spec still describes a permission. So I asked on the thread.

no concerns, security-positive

no concerns

not really a web change, just a heads-up to developers who are talking to a Chrome extension

Generally seems okay, but I followed up for more detail on a "user-initiated action" for opt-out.

no concerns

no concerns


Ken Buchanan

unread,
Feb 19, 2018, 5:34:21 PM2/19/18
to Security-dev
Triaged up to #1389 in https://bit.ly/blinkintents:

No concerns.

(That was the only Intent to Implement thread; the Intent to Ships already had had previous I2Is)

Artur Janc

unread,
Feb 24, 2018, 7:07:25 AM2/24/18
to ke...@chromium.org, security-dev
Triaged up to #1395 in https://bit.ly/blinkintents:

Intent to implement: srcset and imgsizes attributes on link rel=preload
Adding the equivalent of img#srcset|sizes to <link rel=preload as=image>. No concerns.

No concerns.

Intent to implement: WebSockets over HTTP/2
I don't know enough about HTTP/2, but given that this applies only to secure WebSockets, then as long as the usual origin/certificate checks happen at the start of the connection it should be fine.

--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev...@chromium.org.

Daniel Vogelheim

unread,
Mar 5, 2018, 5:47:41 AM3/5/18
to security-dev
Triaged 1395-1401 in https://bit.ly/blinkintents:

Concerns about fingerprinting.
These were raised by Emily in the original intent to implement and are addressed in the "Privacy" section of their explainer, the core argument being that they don't substantially increase finger printing, because it's primarily hardware info which already leaks via numerous other vectors. I'm uneasy with that, since several  "don't substantially increase[s]" tends to add to a quite substantial increase after all, but honestly I don't really know what I could add to the discussion here.

No concerns.

Intent to Implement: :focus-visible pseudo class
No concerns.

No concerns.

Intent to Implement: CSS shadow parts
No concerns.

Disregarded, because no implementation/shipping intent:
- 1395: Extend Origin Trial: Disable Hardware Noise Suppression
- 1401: Experiment: continue experimenting: AudioWorklet


To unsubscribe from this group and all its topics, send an email to security-dev+unsubscribe@chromium.org.

Andy Paicu

unread,
Mar 12, 2018, 4:32:24 AM3/12/18
to security-dev
Triaged 1402-1406 in https://bit.ly/blinkintents:

Intent to Deprecate and Remove: -webkit-box-flex-group, -webkit-box-lines, % values of -webkit-line-clamp
No security concerns, it removes some very low-usage CSS properties that have no security relevance.

No security concerns, seems like a reasonable promise

No security concerns, the Client Hints are only sent on HTTPS and to first-party origins

No security concerns, though this is my own intent. I pinky promise it's a security enhancement.

No security concerns.

Regards,
Andy


To unsubscribe from this group and all its topics, send an email to security-dev...@chromium.org.

--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev...@chromium.org.

Emily Stark

unread,
Mar 31, 2018, 11:44:23 AM3/31/18
to Jochen Eisinger, security-dev

To unsubscribe from this group and all its topics, send an email to security-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev+unsubscribe@chromium.org.

oj...@google.com

unread,
Apr 2, 2018, 7:59:50 PM4/2/18
to Security-dev, joc...@chromium.org
In particular, the API owners discussed #1411 (Generic Sensors-based Motion Sensors) and were hoping to get security sign off. Any chance of making sure that gets reviewed in the next triage?
> <span style="font-size:11pt;font-family:Arial;background-color:tran

Jochen Eisinger

unread,
Apr 3, 2018, 3:49:05 AM4/3/18
to oj...@google.com, Security-dev
I looked at the intents, but forgot to send the email, sorry.

Ojan, if something requires an explicit security or privacy sign-off, it should go through the regular chrome feature launch process so the cross functional teams get notified. We're "only" doing a triage here.

Belated triage of #1407 - #1415 in bit.ly/blinkintents


no concerns


no concerns

Intent to Ship: Numeric separators

(v8 thing, but no concerns anyway)

Intent to Ship: WebAuthentication API

This one has some interesting challenges as it adds the ability to track users (afaik there's a privacy review ongoing), and it exposes maybe unnecessary information about the hardware (see the discussion in the working group about a privacy ca). All of these issues are known, however.

I also don't really like that it's scoped to eTLD+k instead of origin scoped.

On the plus side, it's restricted to secure contexts \o/


My understanding is that this API can be polyfilled using the legacy sensor API, so from that point of view, it doesn't add a new attack surface.

Re the privacy questions, I'd recommend filing a launch bug so the regular cross function reviews (privacy, security UX) look at it.

Intent to Implement and Ship: WebUSB Interface Class Filtering

no concerns

Intent to Ship: Unified Touch adjustment

no concerns


no concerns


no concerns

Ken Buchanan

unread,
Apr 8, 2018, 10:53:38 AM4/8/18
to Security-dev
Triaged up to line 1426 of bit.ly/blinkintents:

Intent to Experiment: WebXR Device API
This is just an experiment with an early draft spec but is intended to replace the WebVR API and has some security implications.

Intent to Deprecate and Remove: Channel ID
Removal seems to be a good thing, the spec proposal didn't catch on and this will be replaced by Token Binding.

Intent to Implement: customElements.upgrade()
No concerns.

Intent to Deprecate and Remove: CSS filter should reject negative brightness
No concerns.

Intent to Deprecate: Nonsecurely delivered cookies
Good.

Intent to Implement: Event Timing
No concerns. This adds the ability to determine when input events have long queue times. Any potential for side channel analysis would be less than for other APIs that already exist (PerformanceObserver, Long Task).

Artur Janc

unread,
Apr 16, 2018, 10:20:35 AM4/16/18
to ke...@chromium.org, security-dev
Triaged lines 1427-1435 in bit.ly/blinkintents:

Security-positive. Charlie, Lukasz and others have spent a fair amount of time figuring out how to protect non-embeddable responses from cross-origin leaks in a web-compatible way; the intent thread, explainer, and Fetch bug have more details.

No concerns.

No concerns.

There are some relatively minor abuse concerns listed in the Security and privacy considerations section of the spec, and this intent doesn't substantially increase the risk. One interesting aspect is the possibility of using the global wake lock state to create a low bandwidth side-channel that may allow communication between cooperating applications across different browser profiles or between different concurrently running UAs. Another issue is that if this API has a small number of use cases, it may be possible for unrelated websites to infer something about user activity ("screen wake lock requested" -> it's likely the user is watching video now); especially in the beginning when there will be few sites using the API, they might be identified cross-origin.

I'm not sure if either of these possibilities is a significant problem, but I filed https://github.com/w3c/wake-lock/issues/124 to consider rate-limiting.

Implement: Keyboard Map
Uhh, is this going to fingerprint my keyboard model? Asked on the intent thread.

There is the usual risk of using fullscreen mode for phishing (i.e. showing a custom URL bar and getting the user to interact with it, after they have been trained that it's part of the browser chrome), but this sounds somewhat far-fetched. It looks like the immediate feature is just about the soft keys for navigation (back / home), so it should be okay. 

Implement: User Timing L3
No concerns.

No concerns.

--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev...@chromium.org.

Andy Paicu

unread,
Apr 27, 2018, 12:49:48 PM4/27/18
to security-dev
Triaged lines 1436-1450 in bit.ly/blinkintents (besides the intent to experiments):

Intent to Implement: WebUSB on Web Workers
No concerns, the worker can't requestDevice so it will have access to it via getDevice after the window has called requestDevice.

No concerns, the `webkit` prefixed properties exist already.

No concerns, it seems like a reasonable measure.

Intent to Implement: WebXR Hit-test
I think this has a lot of privacy implications, they are somewhat mentioned in the explainer but not seriously addressed. I think this will need a privacy review at least.

Intent to Ship: RTCPeerConnection.id
No concerns, did not look to close at it since it's an Intent to Ship.

Intent To Ship: Provide network quality estimates to web servers via Client Hints
No concerns, the fingerprinting concerns are addressed and it is only over HTTPS, did not look to close at it since it's an Intent to Ship.

No concerns, removing this event does not have any apparent security/privacy implications.

No concerns.

No concerns, 

Intent to Implement and Ship: user activation through long-press gesture
No concerns, seems quite reasonable that long presses are user activations.

Intent to Implement and Ship: filtered elements establish containing blocks
No concerns, I don't see anything that is relevant to security/privacy in here.

Intent to implement: Layered API infrastructure
No concerns initially, perhaps it could even be seen as a security improvement as sometimes there won't be a network request to retrieve some library (which could be compromised). I think we should keep a (collective) eye on this.

Regards,
Andy Paicu
--
Regards,
Andy Paicu

Jochen Eisinger

unread,
May 14, 2018, 2:39:32 AM5/14/18
to security-dev
Triaged lines 1451 - 1462 in bit.ly/blinkintents

No concerns

Intent to Implement: async local storage layered API
Polyfill ontop of IndexedDB, no concerns

Nice, no concerns

No concerns

No concerns

Intent to Implement and Ship: RTCRtpTransceiver
Seems like a combination of existing receiver & transmitter, so no concerns

No concerns

No concerns

Intent to Ship: Keyboard lock
This time there's a launch bug, and it got a security review, so good to go from my PoV

Intent to Implement: Intervention reports
Asked on the thread whether there's a risk that this could leak cross origin information.

Intent to Ship: CSS Scroll Snap
No concerns

No concerns

Emily Stark

unread,
May 20, 2018, 11:46:10 AM5/20/18
to Jochen Eisinger, security-dev
Triaged 1463-1467 in bit.ly/blinkintents
Security/privacy-positive

No concerns

No spec, intent will be resent.

This looks like a pretty big change (e.g. running QUIC directly in Blink) so I'm going to suggest they follow the Chrome launch process to get a security review if they're not already.

Left a few privacy questions on the thread.

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Ken Buchanan

unread,
May 27, 2018, 2:40:56 PM5/27/18
to security-dev
Triaged 1468-1480 in Blink Intents:

mkwst already pinged on this to suggest a security review. It is the same as navigating to a URL fragment, causing the new page to automatically scroll to it, but enabling specifying an arbitrary element using CSS selectors. The concern is that there might be mechanisms to leak whether the selector found an element, which would be quite bad. fwiw, I think the clickjacking risk is less concerning, because it doesn't seem to expose any new capabilities. You can already place any pixel of the iframe under the mouse cursor, just by making a large iframe and positioning it with negative left and top values (and then occluding the rest of it with whatever).

No concerns.

No concerns. I2E was looked at last year. This is being held up pending TAG review of the spec.

Promising.

No concerns.

No concerns.

No concerns.

No concerns.

Daniel Vogelheim

unread,
Jun 8, 2018, 11:41:35 AM6/8/18
to ke...@chromium.org, security-dev
Triaged 1481..1491  in Blink intents

1481: Intent to Implement: WebGPU
Successor to WebGL/WebGL 2. General GPU access, for graphics and compute.
No specific security issues, other than an utterly gigantic API surface & complexity.
This should totally be reviewed.

1482: Intent to Implement and ship: Nested dedicated workers
No substantial security implications. There's one bit where they're concerned about excessive resource consumption (e.g. a worker starts more workers in a loop). I wonder if this could be abused in a denial-of-service kind of way.
Minor concerns. Will ask for more info on the list.

1483: Intent to Ship: Request.isHistoryNavigation
No security implications. No concerns.

No security implications. No concerns.

1485: Intent to Implement: Ability to Query User Activation State
We currently use "user activation" to control (usually: block) certain behaviours, i.e. navigation or pop-ups. This aims to expose to JavaScript, so that web apps can make smarter choices. That is welcome, of course, but I'm not sure if a malicious actor couldn't also use the same API to somehow circumvent current protections.
This totally needs a security review, probably from security UI/usability folks!?

Might add to finger-printing surface, but probably doesn't (because the answer would depend strictly on the browser version and/or hardware type. Would be a more a privacy issue.
The launch bug is Launch-Security-Yes (cpalmer) and Launch-Privacy-Yes (dullweber).
No additional concerns, and has already passed review.

No security implications. No concerns.

1488: Intent to Implement and ship: CSS flow-relative margins, paddings and borders
No security implications. No concerns.

1489: Intent to Experiment: Experiment: EventTiming
APIs to expose better timing info to web developers. Timing stuff always has fairly vague finger-printing implications; although I believe this particular change just seems to be a better way of exposing things, and related changes (by the same group of people) to actually improve measuring capability has successfully passed sec & privacy reviews.
No concerns.

1490: Intent to Deprecate and remove: Activation of tabs with window.confirm()
No security implications. No concerns.

1491: Intent to Deprecate and remove: WebAudio Media nodes from OfflineAudioContext
No security implications. No concerns.

Andy Paicu

unread,
Jun 18, 2018, 4:20:35 AM6/18/18
to Security-dev
Triaged 1491-1497 in Blink intents

No concerns as the slot is already exposed in a more indirect way.

No concerns provided that the Security and Permissions section recommendations in the spec are followed in the implementation.

No concerns as it only moves some events to a higher priority queue. The order of events is not guaranteed by the spec anyway.

There are some privacy considerations around fingerprinting using this API. There is a section in the spec but I'm not entirely convinced by it. This should get a privacy review.

No security or privacy concerns. Asked a question about abusing the API to spam windows.

No concerns I don't think this adds anything particularly interesting for an attacker. If you can control a worker, the fact that it can import modules or not seems uninteresting.

--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev...@chromium.org.
--
Regards,
Andy Paicu

Jochen Eisinger

unread,
Jul 2, 2018, 5:02:59 AM7/2/18
to Andy Paicu, mk...@chromium.org, Security-dev
+Mike West, looks like you missed the rotation for 1498 - 1512?

Triaged 1513 - 1516 in bit.ly/blinkintents

Intent to Deprecate and Remove: background-size should not accept negative values
no concerns

Intent to Ship: Web Locks API
It seems that they took care to not allow for locks to be used between browsing contexts that couldn't communicate before, and that all locks are dropped before the page is suspended, so I guess that's ok

Intent to Implement: Gamepad Button and Axis Events
no conerns

no concerns

Emily Stark

unread,
Jul 6, 2018, 7:52:54 PM7/6/18
to Jochen Eisinger, Andy Paicu, Mike West, security-dev

You received this message because you are subscribed to the Google Groups "Security-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

Ken Buchanan

unread,
Jul 16, 2018, 11:19:14 AM7/16/18
to security-dev

Triaged 1519-1529 of the bit.ly/blinkintents spreadsheet --

Intent to implement and ship: TLS 1.3 certificate compression with Brotli
No concerns, this is driven by agl@.

No concerns, this is a usability tweak to the PaymentRequest API.

No concerns. 

Intent to Ship: Intervention Reports
Non concerns.

Intent to Implement: Window postMessage with options
No concerns. This adds a new override to postMessage with an additional dictionary argument.

Intent to Extend Origin Trial: Web Locks API
No concerns.

No concerns.

Intent to Experiment: Stale-While-Revalidate
No concerns.

No concerns.

No concerns.

This seems fine. The user has to grant permission for the origin, as with normal access.


Artur Janc

unread,
Jul 26, 2018, 3:50:22 PM7/26/18
to ke...@chromium.org, security-dev
Triaged rows 1530-1537 from bit.ly/blinkintents:

Intent to implement and ship: queueMicrotask
Intent was withdrawn. Also, no concerns.

Intent to implement and ship: Update behavior of CSS Grid Layout percentage row tracks and gutters
No concerns.

Intent to experiment: Feature Policy JavaScript API
I had a small concern about getAllowlistForFeature(). Asked on the thread.
No concerns ;-)

Intent to implement: Portals
Scary and potentially needs a lot of security love. I'll start a separate thread.

The interactions between sandbox frames and FP make my brain hurt. I asked a couple of question on the intent thread, but I'll have to think about this one more.

Intent to implement: Badging API
Security-positive in the sense that it provides a feature that allows building PWAs instead of Electron apps. Really.

Daniel Vogelheim

unread,
Jul 27, 2018, 9:55:08 AM7/27/18
to security-dev
Triaged rows 1537-.1538 of the bit.ly/blinkintents spreadsheet.

1537: Deprecate and remove: PPAPI (Pepper) WebSocket
Remove an outdated implementation. No concerns.

This changes the handling of 401 & 407 responses. The goal is to better support "Windows HTTP authentication", which apparently wants specific behaviour for those status code. The same behaviour already ships in Firefox & Edge. Despite the scary description, there doesn't seem to be any security consequence here. No conerns.

Ken Buchanan

unread,
Aug 20, 2018, 12:06:24 AM8/20/18
to security-dev
Traiaged rows 1539-1565 of the bit.ly/blinkintents spreadsheet inclusive, representing 3 weeks of intents... :(

Intent to Ship: User Activation (v2)
This hasn't been approved yet, with some ongoing discussion around the proposed specification change. This is security-relevant but as Daniel V noted in the I2I triage last year it makes user gesture behavior more restricted so should be positive.

Intent to Ship: WebSockets over HTTP/2
I don't see any concerns here since it is over a secure protocol.

This doesn't have a specification yet but the description doesn't appear to create any risks.

Intent to Implement and Ship: fractional PointerEvents.offsetX/Y
No concerns.

No concerns.

Intent to Implement: Screen Capture
Redundant with the GetDisplayMedia intent sent in June. Behavior guarded by permission.

No concerns.

No concerns. A minor scope expansion to an existing intervention.

Intent to Implement: hreftranslate attribute
This allows a page to hint to the browser that the target of a link should be translated to a specified language after navigation. There don't seem to be any origin restrictions but I can't see any plausible abuse scenarios.

Intent to Implement: Feature Policy 'lazyload'
No concerns.

No concerns.

Intent to Implement: Writable Files
This wraps the filesystem API. Obviously security relevant, they are actively looking at what permissions model to use. The explainer has more details.

Intent to Implement and Ship: TLS 1.3
Good.

Intent to Implement: Searchable Invisible DOM
No concerns.

No concerns.

No concerns.

Intent to Implement: Feature Policy: animations
No concerns.

Intent to Implement: intrinsicsize attribute
No concerns.

Opus is already supported for playback in Chrome, this just adds it to MSE.

Security positive, it is bad that dialogs can obscure the fullscreen notification.

The spec calls out specific privacy concerns related to the perspective key and includes some mitigations which should be implemented. One person responded to the thread to point out that the feature's hardware dependency creates an additional fingerprinting vector, but that is probably unavoidable.

Artur Janc

unread,
Aug 26, 2018, 1:26:12 PM8/26/18
to ke...@chromium.org, security-dev
Triaged rows 1566-1572 from bit.ly/blinkintents:

Intent to Implement: Pointerrawmove
I have some worries related to the fingerprintability of input devices based on the increased resolution of the event. Asked on the thread.

Intent to Implement and ship: ‘name’ attribute for dedicated workers
No concerns.

Intent to Implement: getMemoryEstimateUASpecific
Scary because it seems to introduce a cross-origin resource sizing leak. I replied on the intent thread.

No concerns, maybe my phone will finally live through the day without charging.

Intent to Deprecate: AppCache
 (♥‿♥)

Not exposed to the web, no concerns.

Daniel Vogelheim

unread,
Aug 31, 2018, 8:33:20 AM8/31/18
to security-dev
Triaged rows 1573 - 1578 from bit.ly/blinkintents:

1573: Intent to Ship: Permission Delegation in M71
Query storage permissions via both Permission API and Storage API (rather than only the latter).
No concerns.

Change access to an existing api. No concerns.

Same as #1573 above. Still no concerns.

Improvements to memory counters, to account for Blink-allocated but V8-owned objects.
The performance.memory API has been repeatedly reviewed because of info leak concerns for multiple tabs running in the same process. This implementation thankfully applies the same value quantization we discussed there. No concerns.

1577 Intent to Ship: globalThis
JavaScript, makes the global object available under another name. No concerns.

Websites can use registerProtocolHandler to register themselves for certain URL schemes. This mechanism is restricted to "safe" protocols. This proposes to substantially increase the list of "safe" protocols.
This does seem to modify how (user) data potentially flows, and on first view this seems potentially security and privacy sensitive.
I'm not seeing anything specifically shocking in the list of extensions; and I believe the browser will not blindly hand over data without a user prompts anyhow. Therefore I have no specific concerns, but I still believe this would best be both security and privacy reviewed.

Andy Paicu

unread,
Sep 10, 2018, 6:55:30 AM9/10/18
to security-dev
Triaged rows 1579-1588 from bit.ly/blinkintents:

1 Intent that requires attention highlighted below

No security concerns. Changes and enhancements to the dictionary returned by a text measuring API.

Intent to Ship: TextMetrics API in Canvas
Duplicate of above, double posted.

No security concerns. Provides an API for encoding and decoding streams of text into bytes and viceversa.

No security concerns. I mostly skimmed it since it's an experiment intent and moreover a request to extend the trial period but from what I gather it seems fine.

Intent to Implement and Ship: queueMicrotask
No security concerns. There are some concerns around allowing another avenue for resource hogging that are also discussed in the bug. I, for one, am happy with the answers in the thread.

===> Intent to Implement: ElementTiming for img Elements
While I don't have any specific and exact concerns I think this might open avenues of attack more so because certain images are registered by default. I've asked for a security and privacy section on the thread.
Perhaps some folks that have previous experience with timing APIs could weigh in on this?

No security concerns. It seems unrelated to security and it's already implemented in two other browsers.

No security concerns. This one is my own I promise it's all good.

Intent to Ship: User Activation API
No security concerns. It seems to me that replacing the current hacky ways of determining whether a page has user input is an improvement and I don't think it exposes anything new.

No security concerns. As mentioned this is what the spec says and what two other browsers implement. Also it makes developers do weird workarounds in order to obtain this behaviour.

--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev...@chromium.org.
--
Regards,
Andy Paicu

Jochen Eisinger

unread,
Sep 21, 2018, 8:30:56 AM9/21/18
to Andy Paicu, mk...@chromium.org, security-dev
+Mike West waiting for your triage report for last week.

I triaged rows 1596 - 1600 in bit.ly/blinkintents

Intent to Implement: Serial API

I don't think this is fundamentally different from WebUSB


No concerns

Intent to Implement: PointerEvent.getPredictedEvents

Looks like this might make pointer movements a better vector for fingerprinting a user. Asking for a privacy considerations section.

Intent to Deprecate and Remove: cache.addAll() duplicate requests

no concerns

Intent to Implement: Crash Reports (via Reporting API)

no concerns

Ken Buchanan

unread,
Oct 1, 2018, 7:55:51 AM10/1/18
to security-dev
Rows 1601 - 1609 of bit.ly/blinkintents (although there are redundant items in 1610 and 1611 right now)

Intent to Implement and Ship: Expose Web Speech API Interfaces
This adds some new methods to the API to align with spec. mkwst@ requested that they look at fuzzing on the interface.

Intent to Implement: Gamepad Touchpad
No concerns.

No concerns.

Intent to ship: Intl.RelativeTimeFormat
No concerns.

Intent to Implement: WebHID (Human Interface Device)
This would need security review before shipping. Aside from the usual permissions considerations similar to WebUSB and the like, there might need to be consideration of the range of HIDs that could be connected and the full range of capabilities that it could be exposing to the web.

Intent to Experiment: Signed HTTP Exchanges
There has been security engagement on this for a while.

No concerns.

Artur Janc

unread,
Oct 10, 2018, 2:54:30 PM10/10/18
to ke...@chromium.org, securi...@chromium.org
Triaged rows 1610-1619 from bit.ly/blinkintents: 

Intent to Implement and ship: FetchEvent.resultingClientId
No concerns (positive in the sense that it helps speed up the AppCache deprecation).

Intent to Implement and ship: RTCRtpTransceiver.setCodecPreferences
No concerns.

No concerns.

Intent to Implement: Autoupgrade Mixed Content (Experiment)
Security-positive.

No concerns.

Intent to implement and ship: RTCRtpReceiver.getSynchronizationSources()
Exposes a high-resolution timer, but this doesn't seem like a problem here.

Daniel Vogelheim

unread,
Oct 15, 2018, 9:33:30 AM10/15/18
to security-dev


1620: Intent to Ship: Screen Capture: Security & Privacy concerns; this needs to be reviewed.
Implmements a 'screen sharing' API. This replaces functionality currently handled in extensions. Compatible implementations already exist in other browsers.
The security and privacy sections in the spec are substantial; several people express security concerns on the intent thread. The team seems a bit defensive about them. tnagel "suggested" this go through privacy review & the team appears to have agreed, but apparently no review was requested. There is a launch bug, with no requests for either privacy or security reviews; so I'm not even sure it's the right bug. 

1621: Intent to Continue Experimenting: Web VR 1.1: No concerns.
Continue an origin trial for WebVR.

1622: Intent to Implement: [Web Perf] Layout Jank API: No concerns.
API to monitor DOM elements changing their on-screen position. No security implications.

1623: Intent to Ship: WebSocket: permit connection reuse for auth: No concerns:
To quote myself from triaging the intent-to-implement for this feature: This changes the handling of 401 & 407 responses. The goal is to better support "Windows HTTP authentication", which apparently wants specific behaviour for those status code. The same behaviour already ships in Firefox & Edge. Despite the scary description, there doesn't seem to be any security consequence here. No con[c]erns.

1624: Intent to Extend Origin Trial: EventTiming. No concerns.
An 'event timing' APi. No security implications.

1625: Intent to Ship: Web Share Target: No concerns.
Allow sites to indicate they can be the target of 'share with' events. Uses mostly system UI. It seems any sharing would require an acutal user gesture, so this ought to be fine security/privacy-wise.

1626: Intent to Experiment: lowLatency canvas contexts: No concerns.
Implements a canvas that doesn't require double-buffering, if system/hardware supports it (with 'it' being hardware overlays; but I'm honestly not quite sure). I'm not seeing any security implications.

1627: Intent to Implement: Streams API: Transferable Streams: No concerns.
API for streams to/from workers. No security implication.


Andy Paicu

unread,
Oct 22, 2018, 10:14:16 AM10/22/18
to security-dev
Triage rows 1628..1632 in https://bit.ly/blinkintents:

No concerns, should cover a bunch of security holes in these versions of TLS.

No concerns, it seems like a reasonable syntax for class fields.

No concerns, at least I don't see anything security/privacy related that is affected.

No concerns, it does not seem to have any security implications.

No concerns, this css feature seems orthogonal to security/privacy.

--
You received this message because you are subscribed to a topic in the Google Groups "Security-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/security-dev/2H3ZiI_INm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to security-dev...@chromium.org.
--
Regards,
Andy Paicu

Jochen Eisinger

unread,
Nov 5, 2018, 4:25:14 AM11/5/18
to Andy Paicu, mk...@chromium.org, security-dev
Triaged rows 1633 - 1639 in https://bit.ly/blinkintents (+Mike West I just included your shift)

no concerns

Intent to Ship Canvas Color Management
I wonder whether this increases the fingerprintability of canvas, but no security concerns

no concerns

no concerns

Intent to Implement FetchEvent Worker Timing
no concerns

no concerns

no concerns

Ken Buchanan

unread,
Nov 12, 2018, 7:31:02 AM11/12/18
to securi...@chromium.org
Triaged rows 1640 - 1642 in https://bit.ly/blinkintents:

No concerns.

No concerns.

Intent to Ship: Intl.ListFormat
No concerns.
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
Message has been deleted
It is loading more messages.
0 new messages