om2

30 ms·

301.
by om2 9y ago
We studied the behavior of many trackers in detail. We believe many track you solely with client-side state (including cookies, indexeddb, LocalStorage, The http cache, etc). It's true that some others use fingerprinting like you descr
302.
by om2 9y ago
The challenge lies in trying not to break any user-facing website functionality. Things like single sign-on, login with Google/FB, Share and Tweet This buttons, CDNs for static content, etc. We also had a goal of not blocking ads. Thes
303.
by om2 9y ago
To be clear, no promises. But we're definitely considering it and it seems like useful functionality.
304.
by om2 9y ago
For now, yes. Our main goal in the short term is interop, since we are a little late to this party.
305.
by om2 9y ago
We did end up using libwebrtc but we had to strip a lot of the dependencies and also update it use system services instead where appropriate.
306.
by om2 9y ago
We'd super appreciate bug reports of reproducible crashes and we definitely try to look at them. Bugs welcome at http://bugs.webkit.org/
307.
by om2 9y ago
I believe Safari will block sleep only if there's actively playing video or audio in a foreground tab.
308.
by om2 9y ago
Unfortunately this test page uses legacy APIs that have been removed from the spec years ago, so it can't give an accurate assessment.
309.
by om2 9y ago
Not in High Sierra / iOS 11 but we're aware of this and considering it for a future version.
310.
by om2 9y ago
Not in the version that will ship in iOS 11 / High Sierra. Not yet determined for future versions.
311.
by om2 9y ago
In a sense you're right. But we also want to make sure WebRTC websites don't blow out your battery, and we went to some effort to make sure it uses efficient video encoding/decoding paths. That said, this was not a majority o
312.
by om2 9y ago
We're working individually with WebRTC sites to get them running. There's complications because many sites use legacy APIs that are not in the spec but still exist in Chrome. We're adding some of those for more compatibility.
313.
by om2 9y ago
WebRTC was the #1 most requested web platform feature for Safari. Now coming to macOS and iOS: https://webkit.org/blog/7726/announcing-webrtc-and-media-cap... You can even try it out now on Safari Technology Previ
314.
by om2 9y ago
Here's the announcement on the WebKit blog: https://webkit.org/blog/7726/announcing-webrtc-and-media-cap...
315.
by om2 9y ago
WebRTC is actually quite complicated to implement and it took a large effort by a big chunk of the WebKit team, even though we had a lot of code that we could reuse. People have a lot of theories about Safari deliberately omitting one featu
316.
by om2 9y ago
It's coming to both macOS and iOS in Safari 11 and iOS 11.
317.
WebKit: Announcing WebRTC and Media Capture(webkit.org)
7 points by om2 9y ago|0 comments
318.
by om2 9y ago
One way would be to not expose any installed fonts to web content other than the system default ones.
319.
by om2 9y ago
Google can indeed track you better when you use Chrome, since Chrome doesn't have Safari's default-on tracking protections.
320.
by om2 9y ago
Our plot to express opinions about ES6 vs ES2105 as names without explicitly disclosing our affiliation in every post has been unmasked! In before: who is "our"?
321.
by om2 9y ago
The WebKit team.
322.
by om2 9y ago
It does seem like being cross-platform makes it more natural for Chrome to lock down the content process very tightly, and provides a strong incentive to do so. On the other hand, it may make it more difficult or less natural to lock down s
323.
by om2 9y ago
We're trying to do the most extreme thing we can do short of blocking ads. To be more effective, you end up blocking ads, whether intentionally or as a side effect. This blocks more than just cookies by the way, it affects all client-s
324.
by om2 9y ago
The network stack has been out of the content process for a super long time, it is not a new thing. (Ironically, Chrome engineers argued strenuously against doing it when we first started). You're right that separate GPU process is a h
325.
by om2 9y ago
This benchmark is only representative for websites built with lots of new ES6+ features. On general JS performance, Firefox isn't quite that far behind (but still behind to the best of my knowledge).
326.
by om2 9y ago
We'll probably use years for the future versions. ES6/ES2015 was a much bigger change than we're expecting from the next few versions so it seemed like a good point to make the break.
327.
by om2 9y ago
You actually did make a claim that Safari's sandbox was in particular worse than Chrome's, in the post I directly replied to. That is what got my dander up. Elsewhere you implied that the Safari sandbox comparable to the Java sand
328.
by om2 9y ago
The question is a bit complex than a simple reading of these files. Mac OS sandboxing allows dynamic extension of the sandbox, which would not be reflected in the profile (I'd bet Safari does more of this than Blink though). Also, as y
329.
by om2 9y ago
Your original post here made a bold claim with no qualification and no supporting details. You're not providing any backing to your claim but at the same time you're asking me to give details. Plus you've repeatedly thrown in
330.
by om2 9y ago
This post has lots of info about Chrome and Edge RCE defenses. Super informative on this front. But is surprising light on detail about what makes their sandbox more robust than Edge's. (I don't know near enough about the Edge san

More ›