Re: [webkit-dev] Request for a position on the Idle Detection API

[Ryosuke Niwa]

On Wed, Oct 28, 2020 at 4:56 PM Reilly Grant  wrote:

> I would like to request an official position from the WebKit team on the
> emerging Idle Detection API  
> specification.
> I am aware that this API was included in a list of APIs
>  which you have decided not to
> implement due to fingerprinting concerns. I assume that this objection was
> based on the original explainer provided for this API.
>

Our position has not changed. Our concerns are not limited to
fingerprinting. There is an obvious privacy concern that this API lets a
website observe whether a person is near the device or not. This could be
used, for example, to start mining bitcoins when the user is not around or
start deploying security exploits, etc...


> Since that list was posted the API has been extended to include a
> permission that sites must acquire before being granted access to user
> presence signals. I would like to start a conversation to understand the
> fingerprinting risks you foresee from this API.
>

This kind of action-at-a-distance permission prompt is problematic because
it's unclear to the user why such a permission should be granted and for
what purpose.

Additionally, the use cases listed at
https://github.com/WICG/idle-detection/blob/master/README.md are rather
weak.

Chat application: presenting a user's status to other users and delivering
> notifications to the device where the user is active.


Why does delivering a notification to all devices considered bad? That's
what happens to most notifications I receive and modern operating systems
have ways to hide & dismiss old notifications anyway. It's also unclear how
users are supposed to know of this use case when assessing whether to allow
a permission for this API or not.

Showing timely notifications - e.g. deferring displaying feedback until the
> user returns to an active state.


Again, it's unclear why this is desirable. If I'm not at a computer, it's
okay for the notification to still arrive. I'd see it when I come back to
my computer.

Updating an outdated service worker when there's no unsaved state by
> triggering reloading of the tab.


This doesn't seem like something you'd need idle detection API to do. It's
sufficient to realize that you haven't recently received user inputs on
your website. I have plenty of tabs & windows that I don't touch for hours
if not days. Any websites loaded in such browsing contexts should consider
doing that kind of updates / synchronization. If the argument is that the
user may go back to such tabs / windows if they're currently present, then
this user idle detection API won't help either because the user may come
back to it at any moment.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Transition to Git

[Maciej Stachowiak]

> On Oct 13, 2020, at 2:37 PM, Konstantin Tokarev  wrote:
> 
> 
> 
> 13.10.2020, 22:33, "Maciej Stachowiak" :
>>>  On Oct 2, 2020, at 10:59 AM, Michael Catanzaro  
>>> wrote:
>>> 
>>>  On Fri, Oct 2, 2020 at 6:36 pm, Philippe Normand  wrote:
  Would you also consider preventing merge commits in order to keep a
  clean mainline branch?
>>> 
>>>  Big +1 to blocking merge commits. Merge commits in a huge project like 
>>> WebKit would make commit archaeology very frustrating. (I assume this is 
>>> implied by the monotonic commit identifiers proposal, but it doesn't 
>>> exactly say that.)
>> 
>> I’m assuming your objection is to regular merges, but how do you feel about 
>> squash merges? Or do you think all PRs should be landed by rebasing?
> 
> I'm not Michael but will add my 2 dollars anyway :)
> 
> In these two approaches commits inside PR have different meaning, and 
> workflow is different.
> 
> Below I use a term "atomic change" to describe minimal code change which is a 
> self-contained work unit with following properties:
> * It implements well-defined task which can be summarized as a short English 
> sentence (typical soft limit is 60 characters)
> * It doesn't introduce defects (e.g. bugs, compilation breakages, style 
> errors, typos) which were discovered during review process
> * It doesn't include any code changes unrelated to main topic. This 
> separation is sometimes subjective, but it's usually recommended to split 
> refactoring and implementation of feature based on that, bug fix and new 
> feature, big style change and fix or feature.
> 
> AFAIU our current review process has similar requirements to patches 
> submitted to Bugzilla, though sometimes patches include unrelated changes. 
> This can be justified by weakness of webkit-patch/Bugzilla tooling which has 
> no support for patch series, and by fact that SVN doesn't support keeping 
> local patch series at all.
> 
> 1. Workflow 1 - "Squash merge" policy
> 
> * Whole PR is considered to be a single atomic change of WebKit source tree. 
> If work is supposed to be landed as a series of changes which depend on each 
> other (e.g. refactoring and feature based on it, or individual separate 
> features touching same parts of code), each change needs a separate PR, and, 
> as a consequence, only one of them can be efficiently reviewed at the moment 
> of time
> * Commits in PR represent review iterations or intermediate implementation 
> progress
> * Reviewers' comments are addressed by pushing new commits without rewriting 
> history, which works around GitHub's lack of "commit revisions". Also this 
> workflow has lower entry barrier for people who haven't mastered git yet, as 
> it requires only "git commit" and "git push" without rebases.
> 
> 2. Workflow 2 - "Rebase" ("cherry-pick")) or "Merge" policy
> 
> * PR is considered to be a series of atomic changes. If work consists of 
> several atomic changes, each commit represent an atomic change
> * Review iterations are done by fixing commits in place and reuploading 
> entire series using force push (of course if review discovers that 
> substantial part of work is missing it can be added as a new atomic commit to 
> the series)
> * It's possible to review each commit in the series separately
> * Workflow requires developers to have more discipline and experience with 
> using git rebase for history rewriting. Entry barrier can be lowered by 
> providing step by step instructions like e.g. [1]. 
> 
> 
> Workflow 1 is more like what we have now with Bugzilla.
> 
> Workflow 2 is used by many projects which use git for a long time and value 
> high-quality commit history. It's used e.g. by Linux kernel, or projects 
> which use Gerrit as a review tool (Chromium, Android, Qt, etc). It advantages 
> for developers (who can submit more work to review at the same time without 
> risk of mixing up unrelated changes together), reviewers (it's easier to 
> review atomic changes than those with too high or too low granularity), 
> maintainers of stable branches (they can pick bug reports and avoid at least 
> some unneeded refactorings, features and style improvements).
> 
> Workflow 1 is the most obvious way to use GitHub, because it doesn't make any 
> hints about existence of workflow 2. However, many projects which use GitHub 
> for code review and value high-quality history are using workflow 2. For 
> example, see Ryosuke's example with whatwg/html repo.
> 
> Workflow 2 is facilitated by Gerrit, which doesn't require using force pushes 
> and makes it immediately obvious for new user if they start adding new fixup 
> commits instead of editing those being reviewed.
> 
> Workflow 2 can use both rebase and merge strategies, and merge isn't so evil 
> in this case. However, using merge moves responsibility for solving conflicts 
> from contributor to repository maintainers, which doesn't scale well. 
> Projects which accept patches via mailing lists, like Linux kernel, imply 
> 

Re: [webkit-dev] Request for a position on the Idle Detection API

[Simon Fraser]

Can you describe what a permission prompt would look like that allows the user 
to make an informed decision about whether they should allow or deny the 
permission?

Simon

> On Oct 28, 2020, at 4:56 PM, Reilly Grant  wrote:
> 
> Greetings WebKit engineers,
> 
> I would like to request an official position from the WebKit team on the 
> emerging Idle Detection API  
> specification. I am aware that this API was included in a list of APIs 
>  which you have decided not to 
> implement due to fingerprinting concerns. I assume that this objection was 
> based on the original explainer provided for this API. Since that list was 
> posted the API has been extended to include a permission that sites must 
> acquire before being granted access to user presence signals. I would like to 
> start a conversation to understand the fingerprinting risks you foresee from 
> this API.
>   
> Reilly Grant
> Software Engineer
> reil...@google.com 
> Google Chrome
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Concurrent display list item writing and reading in the GPU process

[Wenson Hsieh]

Hello webkit-dev!

I’m writing to let folks know that we’re planning heavy refactoring around 
WebKit’s display list architecture (WebCore::DisplayList) as part of a broader 
effort to use the GPU process for rendering webpages, without significantly 
regressing performance (particularly, graphics performance).

Currently, when using the GPU process, calls to GraphicsContext methods in the 
web process are converted into (largely) platform-agnostic DisplayList::Item 
objects, which are then propagated to the GPU process via IPC in batches of at 
most several hundred items. In the GPU process, these decoded display list 
items are then applied to platform-backed GraphicsContexts (e.g. on 
CoreGraphics platforms, this is a GraphicsContext with a nonnull CGContextRef).

This introduces significant overhead, due to how:

- The web and GPU processes must respectively encode and decode each display 
list item, adding overhead for each item that is sent and handled. This hampers 
both the throughput and latency of display list rendering, by making each item 
slower to process.
- As the web process is generating and batching these display list items, the 
GPU process cannot immediately begin processing display list items until they 
have been received as a single batch (i.e. a WebCore::DisplayList). This 
primarily affects the latency of display list rendering.

To mitigate this, we plan to transition to an architecture wherein display list 
items are directly written to and read from shared memory between the web and 
GPU processes. This allows the web process and GPU process to concurrently 
write and read display list items, and additionally elides the overhead of 
encoding and decoding each item.

Additionally, to uphold security guarantees in the GPU process, display list 
items that are stored in shared memory must have no pointers, and may only 
contain data structures with no pointers; with careful validation, this should 
prevent a compromised web content process from writing display list items 
capable of triggering arbitrary code execution in the GPU process.

In working towards this goal, our first step is to refactor DisplayList::Item 
and all of its subclasses such that they don’t contain any pointers (including 
vtable pointers), and that they instead reference any “out of line” resources 
required (for instance, image data, or extended color information, or an 
arbitrarily complex WebCore::Path) via fixed-size integer identifiers. Data for 
these resources would be copied into shared memory, with the expectation that 
this data is (securely) decoded and validated in the GPU process.

While this email is mostly informative, we are also curious whether this 
overall architecture will be compatible with non-Cocoa ports (for instance, WPE 
and GTK), as most of our planning so far has been done within the context of 
enabling GPU process for Cocoa platforms.

Thanks,
whsieh___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position on import maps

[Domenic Denicola]

Thanks for your response Ryosuke!

From: Ryosuke Niwa  

> How does this feature supposed to work with CSP subresource integrity?
>As far as I've read various specs and the proposal, it's not currently 
>possible to specify any integrity checks on modules loaded via import this. 
>This is a pretty serious downside because it would mean that any remote server 
>ever referenced by an import map becomes a security liability for a given 
>website. It's a lot worse compared to normal scripts > because of the 
>action-at-a-distance of import maps. There is no indication that a given 
>module import could involve access to cross-origin servers isn't obvious from 
>where the import statement appears.

Correct, this proposal does not change the status quo regarding models and CSP 
integrity integration. I can understand how import maps might increase the 
priority of improving CSP in that way for WebKit, and I imagine the webappsec 
group would welcome any collaboration on solving that. 

There are even proposals from community members to piggyback on the import 
map's