Present: Daniel Appelquist, Tim Berners-Lee, Domenic Denicola, David Herman (afternoon), Yehuda Katz, Sergey Konstantinov, Yves Lafon (remote), Peter Linss, Mark Nottingham, Alex Russell (afternoon), Jeni Tennison
Guests: Dominique Hazaël-Massieux (for discussion on Permissions)
Chairs: Daniel Appelquist, Peter Linss
Scribes: Mark Nottingham, Domenic Denicola, Sergey Konstantinov
- EME
- Captive Portals
- Tooling / Github / Etc…
- Spec Reviews
- Permissions
- Spec Reviews (continued)
- Privacy
### Topic: EME
Domenic: Spec editor came to us at the last meeting to help us understand the current state of EME and answer our questions.
Domenic: I worked out a proposal to make EME more "webby" -- more conformant to shared values of privacy, platform independence
Domenic: I submitted a revised version of our opinion, stating concerns rather than solutions
Domenic: Sergey reviewed, accepted pull request, then sent a followup which we need to discuss
Domenic: Also, we got a reply from Mark Watson (Netflix) on list, which is good. His feedback was mostly about phrasing, softening things, etc. which I think we can address and is worth doing.
Domenic: It'd be great to issue this as a finding that can be referenced as a TAG opinion when closing bugs on the spec.
mnot [ group looks at document ]
twirl https://github.com/w3ctag/eme/blob/master/EME%20Opinion.md
Domenic: Sergey has an alternative design that he'll take to the group as potential future work.
Domenic: EME has momentum; it's shipping in most browsers, vendor-prefixed; we're just trying to limit the damage.
Domenic: We may still get EMEv2 or DRMv2 e.g., based upon public key cryptography, but that's a multi-year effort.
TimBL: I'd encourage Sergey to do that.
twirl Further reading: w3ctag/eme#8
twirl And http://lists.w3.org/Archives/Public/www-tag/2014Sep/0039.html
mnot [ group reviews pull request ]
Domenic: Sergey proposed sections on fraud prevention, accessability, fair use, anti-circumvention
Domenic: My opinion is that these are outside the scope of criminal activity
TimBL: I disagree
Peter: The whole point of DRM is to prevent criminal behaviour
TimBL: You don't have to say "fraud"; it could be "attack"
Domenic: That could be OK; "attack vector" is better
Sergey: I agree with Domenic; this shouldn't be limited to criminal behaviour. I'm 100% sure that some vendors will give you a license with additional restrictions. So let's make it clear that the user has to be able to read the license.
JeniT JeniT has joined #tagmem
TimBL: ... or you could leave affordances for regulators so that they can make appropriate limitations.
Domenic: We should be concerned about the user, and phrase it that way.
Domenic: The main point is that the user should be able to inspect the license, as this helps prevent attacks.
Domenic: "Fraud" is less concrete than "attacks"
ACTION Domenic and Sergey to re-phrase "fraud" as "attacks"
trackbot Created ACTION-876 - And sergey to re-phrase "fraud" as "attacks" [on Domenic Denicola - due 2014-10-07].
mnot Next - Accessibility
Domenic: I don't think this works. It's saying that in a hypothetical future when they can translate video, we should punch a hole in EME for that technology.
Domenic: I would rather approach this as saying that text tracks should not be encrypted. I have feedback that this is feasible and not highly controversial.
Domenic: If we want videos to be accessible, we'd need a huge societal / legal effort.
Peter: There are high contrast modes, e.g., those applicable to images.
Peter: The video stream shouldn't be lopped out of that, e.g., if the browser is in high-contrast mode.
Peter: A solution could be that the requirements can be pushed down.
Domenic: If we soften it to "The normal accessibility modes of videos should be available."
Sergey: [ draws diagram CDN - CDM - Hardware with pipe between CDM and Hardware to "System Service" ]
Domenic: System services could give instructions to CDMs to help accessibility
Peter: It could be a filter that has to be applied
Domenic: these are specific technical solutions; there could be others
Sergey: So we just add a note
Domenic: yes.
ACTION Domenic to add a note generally encouraging accessibility in EME opinion
trackbot Created ACTION-877 - Add a note generally encouraging accessibility in eme opinion [on Domenic Denicola - due 2014-10-07].
mnot Next - fair use
Sergey: Amazon displays books in the browser, and you can't copy it. The HTML was a complete mess of iframes, etc.
Sergey: In a short time, everything will be like that.
Domenic: I worked for bn.com and we did ebooks. E.g., you were granted 45 pages of copying every thirty days.
Torgo: Because it's important in an academic context
Domenic: yes
Torgo: The thing about fair use is that it's specific to jurisdiction, and varies quite a bit.
Torgo: IANAL
Torgo: AIUI the EU doesn't have a concept of Fair Use
TimBL: Yes they do
JeniT: It was never there as far as I'm aware, at least called "fair use"
mnot Torgo radiates joy
Torgo: There's work going on on a EU copyright overhaul
Torgo: My point was that it's not universal
Torgo: DRM stops users from doing things that are legal any way; e.g., excerpt of a video, which is legal under many copyright laws
Sergey: video companies think that all copying of videos is illegal
Domenic: Do we want to soften this to something like "We know that DRM and Fair Use have been in conflict, and would encorage discussion"
mnot [ derision erupts ]
Torgo: My thinking is that it'd be useful to say something like "DRM often foils people from doing something that's legal for them to do, according to their copyright law. This issue is not addressed in this document."
Domenic: That's only useful from the perspective that Tim brought up -- that future lawmakers might find it useful.
JeniT: Does that even make sense as a position though? Lots of tools don't let us do things that are legal for us to do.
Torgo: They restrict you from doing something that you could otherwise do on the Web, under the pretense that you can't do this because it's illegal.
TimBL: We talk a lot about UI quality and principles. In a way, to say we're introducing something that restricts the UI is a UI issue.
TimBL: What does the TAG think about web sites that add their own link and attribution when you copy?
Domenic: I think it's horrible
Peter: We can't technically restrict people from being annoying; we'd shut down the entire web.
JeniT: I think the usability aspect is important
Domenic: How can we say that constructively?
Peter: It's breaking the whole "view source" model on the Web
Domenic: That's a can of worms
Peter: There's a lack of developer tools; EME could prevent them from coming about
Domenic: That argument means "no CDM"
Peter: Or it means that the CDM exposes the content in a trusted way
Domenic: The point of DRM is that there is no trust.
Domenic: That might be a good motivator for DRMv2
Domenic: Kill it?
mnot [ group seems to agree ]
mnot Next - Anti-Cirumvention law
Domenic: This is an interesting one; not sure what to do with it.
mnot: what vulnerabilities would they be looking for?
Domenic: Like anything that ties into the OS
Peter: it has low-level access to the hardware
mnot: This seems like a purely legal problem
Domenic: agreed, but it's a good problem to bring up
TimBL: why is this a legal problem?
Domenic mnot: the problem is stated that there's legal exposure for people who try to do penetration testing. that's in the legal realm
Domenic timbl: so it's a problem that should be solved by changing the law, not changing the technology?
Domenic mnot: i don't see how else
Domenic timbl: well, if the whole setup was different (e.g. open source DRM), it would no longer be a legal problem
Domenic mnot: but that's a pretty radical thing to put into the document
Domenic timbl: agreed, not at this point, although a radical re-engineering is still a good idea over a longer timescale
Domenic timbl: but we should raise the concern
Domenic mnot: indeed, if only to give affordances to lawymakers later
Domenic: My intuition is that you couldn't design a spec to make it not possible to sue (sergey's suggestion)
Domenic: However, we could have something like an equivalent to the patent policy; "I won't go after pen testers"
Domenic: We'd need to talk to the AB about that
TimBL: AB might not be appropriate. It's worth pointing out that there are other possible protocols; it's half legal and half engineering
Domenic: I only suggest the AB because they have experience with the patent policy.
Domenic: I do like this feedback and suggest we do something with it; not sure where it belongs.
Torgo: I like the idea of a covenant.
mnot: +1
TimBL: Using SMTP as a model; suppose that the mail RFCs said that conforming use of the To: header is that it's used to give a functional address for the social entity that sends the e-mail. A conforming user is one that does these things...
TimBL: You then leave it open for regulators to use that.
Domenic: Making spec into certifications is a big thing
TimBL: That's different
Domenic: I think we should remove this from the document, but draft a communication to the AB asking for collaboration
mnot: Will it do harm in this document?
Torgo: Then we can point to this when we talk to the AB
Domenic: I think it needs to be separated. A lot of this is about concrete restrictions on the API; this is a separate concern.
Peter: This fits under the category of security concerns.
Domenic: good point
Domenic: We'd want to modify it into "We'll be investigating this..."
Peter: Say that this is a hole that we don't want to leave open
mnot: As long as we make it clear that we don't expect them to solve this problem.
Domenic: I appreciate the notion that this could be built on top of web crypto, but don't think it's directly relevant
mnot group resolves to rephrase, make it clear that this is an action for the TAG, not EME; make it clear that this is a security risk, put under security section ]
mnot Looking at Mark Watson's feedback
Domenic: There are four points.
Domenic: First - phrasing of "The ability of the CDM to potentially run arbitrary code is a hole in the web platform's security model."
Domenic: He has a point; e.g., Flash
Domenic: OTOH it's aritrary from the standpoint of the user, and opaque to the user
Domenic: We can either change from "arbitrary" to "unspecified" or add a sentence giving context
Sergey: With Flash, SWF are a set of instructions. With EME, we don't know that video is just data, not code.
Domenic: So restrict what data goes in and out?
Sergey: Yes, so only data goes in and out
Domenic: That seems to go against years of computer science
Domenic: Oh, you're saying that frames shouldn't smuggle code?
Sergey: Yes
Domenic: There is no restriction that it is video presently?
Sergey: They're talking about using standardised form of encrypted video. But the license response could contain instructions for the CDM.
Domenic: I think this is worth bringing up in our reply to Mark; it may not change what we put in the document though. I haven't talked with many people about the license response.
Domenic: Second concern - "As part of interoperability, EME should not provide APIs that are designed to allow restriction of content to one platform and/or key system."
Domenic: We should do a more thorough investigation by what is meant by this.
Peter: Isn't it the opposite, that EME is failing to provide universal APIs?
Domenic: I think we covered that pretty well.
Domenic: More investigation needed.
Domenic: Third concern - "While certain key systems may only be supported on certain platforms, and certain content may only be available with certain key systems..."
Domenic: I'm not sure what he's concerned about here.
mnot: he seems to be just noting something.
Domenic: Fourth concern - "We understand that designing a DRM system for the web brings along robustness requirements that are unlike those of most Web APIs..."
Domenic: My take is that this is not very relevant.
TimBL: He's saying "Don't focus on robustness."
TimBL: Maybe he's saying that people should be allowed to think about systems that don't have robustness
Domenic: I want to push back because I don't see this expressed in the EME document
mnot: We're not writing a requirements document; it doesn't have to be complete
Domenic: Maybe he's concerned that we're mischaracterising it
mnot [ side conversation between Domenic and Sergey ]
Domenic: Tim's point is that we shouldn't say "necessary for robustness" as if that were a feature for all DRM
Domenic: ... but EME has chosen to address DRM in this way
Peter: You could address this by removing the word "robustness" from that sentence
Domenic: OK
Domenic: I like this, because it addresses Tim's and mark's comments
Domenic: Or say "Robustness or IPR"
Torgo: I like Peter's suggestion more
Torgo: Keep silent on the motivation
Domenic: That's it for EME
timbl http://tag.w3ctag.org
plinss https://pad.w3ctag.org/
timbl “
timbl The web address you've requested doesn't exist
timbl The web address you have requested is incorrect or does not exist. You could try amending the spelling or check the web address.
timbl ”
timbl Pppht
mnot [ group agreed to send this as spec feedback ]
### Topic: Captive PortalsDomenic { "&" : "&"} ===> <json:string name="&">&</json:string>
mnot: we've talked about captive portals a lot in the IETF and elsewhere
mnot: if we wanted to try to do something, we could probably get the right people from places like Cisco, Microsoft, Apple, the browsers, ...
mnot: where we're at now, is, "what can be realistically done?"
mnot: we've had preliminary discussions mapping out the problem space, figuring out back-compat constraints
mnot: big question is what is the right layer to interpose these things
mnot: we have a status code in HTTP for this, but you can't intercept that when you go over HTTPS
mnot: anecdotally I've been seeing fewer captive portals, just WiFi passwords
Domenic (the room disagrees)
mnot: a common use case is just showing some text before a user connects
Yves well, ssl should show certificate issues if connected to a captive portal
Domenic (discussion of various problems with bad cert errors upon connecting to a network and how this is only getting worse)
timbl: i could see OS designers lying, saying "there is no network," until they can detect actual internet
mnot: yes, but there is a war between the networks and the OSs, some captive portals want to overcome captive portal detection
dka: this is why apple has 100 different domains to detect this...
mnot: it's only getting worse because Apple is doing MAC address randomization, causing captive portals to lose their ability to remember you
mnot: low hanging fruit would just be documenting what OSs do right now
timbl: what would it look like to design this from scratch?
mnot: we need a transition stategy
timbl: no, I'm more interested in benevolent places like MIT
mnot: my gut is if you wanted to do this from scratch it would be part of 802.11
plinss: what about DHCP?
mnot: we're trying to get away from that; inherently insecure
plinss s/plinss:/timbl:/
timbl: "here's your IP address; it's not going to work until you visit this web address"
Yves DHCP is insecure, but still you configure your interface (and dns settings) using dhcp replies
mnot: but because of how DHCP works, anyone can announce that to you, so it's a great way to phish someone in a coffeeshop
timbl: are we ratholing?
mnot: the problem is captive portals are full of ratholes like this because it's full-stack
timbl: i'm interested in solving this for enterprises and universities...
mnot: well universities have alreayd solved this with e.g. eduroam...
plinss: (but it's still a crappy implementation)
plinss: opportunity to invite some of the other parties around TPAC?
mnot: I was thinking more a full-day workshop. And TPAC is only a couple weeks away
mnot https://github.com/httpwg/http-extensions/wiki/CaptivePortals
timbl timbl has joined #tagmem
plinss: I'd like to see an end result of "ideally, here's a spec for a good captive portal"
Domenic (discussion of a "brand" for well-designed captive portals and related stuff)
mnot: my gut feeling is that this is a long-term thing
mnot: perhaps an event of early to mid next year
plinss: perhaps adjacent to EWS in April
mnot: concrete next steps---work on the wiki, talk to people to set up a meeting, maybe come up with a plan for a plan
Zakim Zakim has left #tagmem
timbl Hitler reacts to the HTML5 URL normative reference controversy - See more at: http://meemsy.com/v/22036#sthash.I7RqFP9V.dpuf
timbl The last bit was snuck in by the site — how?
twirl ScribeNick: twirl
### Topic: Tooling / Github / Etc…dka Starting Up Again
twirl mnot:
twirl mnot:
twirl mnot:
twirl mnot: Markdown rules
twirl mnot: The hardest decision is doing something with our home page
twirl dka: I think it's a high priority task
twirl dka: EME is a good example, it's actually spec review but it's not in spec reviews repo
twirl mnot: Chairs should control repo creation
twirl [ disagreement ]
twirl [ mnot is very persuasive ]
twirl [ discussion on whether github wiki is better than TAG Wiki or not ]
twirl [ discussion on using wiki vs repos ]
twirl mnot: Repos could be used offline
<bkardell_> bkardell_ has joined #tagmem
twirl mnot: And github wiki too :)
twirl mnot: github wiki is a separate repo
twirl [ mnot explains how HTTP2 repos are organized ]
twirl [ discussion on organizing indexes ]
twirl dka: proposes (a) move to tag.w3.org -> w3tag.github.io, (b) move meeting organization to github, (c) move minutes to github
twirl (d) move all current work to main page, (e) move EME to Spec Reviews repo, (f) clean up repos, (g) backup everything, (h) elaborate policy on repo creation
twirl mnot: are we ok with breaking URLs?
twirl timbl: I think its important to preserve URLs
twirl s/its/it's
twirl [ dka explains our current policy ]
twirl plinss: let's proxy all URLs into W3C space
twirl [ timbl explains how to convert cvs subtree ]
twirl [ plinss explains how to synchronize github and w3c space ]
twirl plinss: Minutes URLs MUST be preserved
twirl dka: Having our documents in github, having clear repos are good ideas
twirl dka: But I'm very concerned about preserving URLs history
twirl [ general discussion ]
twirl dka: We could put on our home page everything which changes rarely, and have a separate gh-page for current work
twirl mnot: I could try to convert our old stuff
twirl [ discussion on CVS -> git conversion ]
twirl mnot: what about gh issue tracker?
twirl mnot: two trackers are confusing
twirl [ historical joke from dka ]
<bkardell_> ...But GH is very Dev friendly
twirl dka: the problem is that each repo has its own tracker, so you can't see all w3c tag issues
twirl mnot: let's use Arch tracker for long-living issues
twirl [ discussion on confusing trackers ]
JeniT all issues: https://github.com/organizations/w3ctag/dashboard/issues/repos
twirl dka: let's setup a repository for "TAG" issues
twirl dka: and close w3 issues
twirl mnot: what to do with spec reviews wiki page? let's put in README in specreviews repo
twirl [ dka tells the story about agendas in cvs ]
twirl dka: let's move agendas to github
twirl mnot: what's the metrics of success?
### Topic: Spec Reviewstwirl [ memes, videos, number of documents ... ]
twirl Domenic: we were asked to review WebApps specs
twirl Domenic: WebCrypto is done
twirl twirl: Web Animations review is done
twirl mnot: HTTP2 reviewed
twirl [ reviewing w3c issue tracker ]
twirl mnot: Get off My Lawn: closed
twirl http://lists.w3.org/Archives/Public/www-tag/2014Jun/0004.html
twirl http://lists.w3.org/Archives/Public/www-tag/2014Jun/0002.html
twirl mnot: CSS Regions?
twirl [ plinss explains elements flows ]
twirl dherman: Is there any progress with box trees?
twirl plinss: yes, we are moving
<bkardell_> Was a task force set up?
Yves good also to put the discussed scope in the issue description
twirl [ looking at: CSP2, Mixed Content, Referrer Policy, ... ]
twirl Domenic: I've reviewed Referrer spec, found some issues
twirl [ mnot and Domenic take this issue ]
twirl [ Domenic explains SRI problem ]
twirl mnot: there severals spec related to URL metadata
twirl s/spec/specs
twirl s/there/there are
twirl Domenic: best way to do spec reviews is talking to author directly
dherman "on their turf" is a powerful point
dherman "TAG is here as a service" <== good attitude
twirl [ Screen Orientation is done ]
dherman "come over to my house and let me tell you how you're wrong" <== bad attitude
dherman TAGaaS
twirl [ multipart/form-data ]
twirl mnot: it's already Last Call
JeniT (presumably the previous version)
twirl Domenic: looks cool, there are tests
twirl [ work suddenly stopped ]
https://github.com/masinter/multipart-form-data/issues/17#issuecomment-48077041
twirl [ reviewing multipart-form-data issues ]
twirl [ off-topic: mnot complains about implementing HTML5 ]
twirl [ agreed to propose something by TPAC ]
twirl mnot: Wake Lock
twirl Domenic: I'm already involved
twirl I'd prefer to have a simple API
twirl s/I'd prefer/Domenic: I'd prefer
twirl [ reviewing proposed use-cases ]
mnot: Full Screen: closed
twirl mnot: Manifest?
twirl Domenic: It's for installable webapps; related to packaging
twirl mnot: WebRTC Identity Provider Selection
twirl Domenic: bizzare thing, something like invisible iframe
slightlyoff OMW
slightlyoff hey all
slightlyoff terribly sorry
slightlyoff meant to join 2 hours ago and failed = \
dom dom has joined #tagmem
### Topic: Permissionsslightlyoff worse in many, many ways = )
slightlyoff terribly sorry for how long that took
dka https://gist.github.com/slightlyoff/43cd8c2f64a0719358fe
Alex there are several key aspects
... you can request a permission at page load
... you may build UI using API calls results
... all these things are async
... and user can always say no
... we can imagine lighter UI than prompts if user trusts that app
... we have lots of experience with mobile apps sync permission dialogs, and its disappointing
... there is a trade of remembering webapp permissions vs. leaking this information
twirl: how to revoke permissions?
Alex: I separated UI from API in a document
twirl: but how will webapp know its permission revoked?
Alex: ask each time
Domenic: but how to restyle UI?
Alex: probably perission change event
Dom: I like this proposal
... we discussed those questions, I think it's a good starting point
[ discussion on requests ]
Alex: the question is whether it reasonable to create separate API requests to each action
mnot: there is no easy answer, in mobile APIs too
Alex: you should have a freedom to change your mind
Alex: we could do that in extensible way, with low-level API
dom: It would be great if TAG provides more guidance on securing the Web
slightlyoff I am still working on the origin post, it's much harder
slightlyoff so I have an idea of where we're going here
slightlyoff I can outline it briefly
dom: We need a clear picture of future web security
Alex: there are good success stories from OSes, we should work on browser UI
... we should think about "installation" for webapps
slightlyoff I don't think WG's are the right place to be litigating these issues
dom: we need even broader picture
slightlyoff nearly all the important security UI is owned by the UA
Domenic permissions, origins, crypto, UI
slightlyoff and that's increasing over time
Domenic (i really like this idea that we should lay out the landscape of how all those things interact)
Alex: we now have some legacy, files, we can't ask, for example, a single contact information
dka ok thanks Dom!
timbl: I need to understand why app wants to have some particular access, I have to trust it completely
Alex: we may think for example about manifest, so user could understand what application is
twirl ... I don't believe we have answers; for example, should permissions be granted to app working in iframe, etc
twirl s/answers/all answers
twirl [ timbl on peculiar requests bouncing in Chrome ]
dka dka has joined #tagmem
twirl [ discussing the problem of sending credentials with CORS ]
Alex: Credentials are the most valuable permission, more sensitive than raw socket access
timbl: imagine that I'm trying to write really good calendar, I need to be able to get information from all other sources
twirl ... at present moment ony Facebook could be such super application
twirl ... that's reputation question
Alex: my experience tells that user doesn't understand what really happens
twirl [ discussion on service workers which help to solve these problems ]
dka: Dom asked could we document security model beyond permissions
timbl timbl has joined #tagmem
twirl ... and that's an action for the TAG in my view
Alex: I've been working on origins post
twirl ... we need to evaluate question how much more could you trust smth, there is no answer right now
twirl ... Service Worker is a thing which controls origins since it sees all requests
mnot: we have same problems with proxies
twirl [ Service Worker Union, we need it ]
timbl http://www.seiu.org
timbl clientside proxy
slightlyoff timbl: we avoided that because it doesn't describe the other background stuff we can do with it, e.g. responding to Push messages
### Topic: Spec Reviews (continued)slightlyoff timbl: also, I'm going to look into the XHR/fetch credentials thing and see what conditions we can relax it under
slightlyoff thanks for bringing it up
mnot: Shadow DOM
twirl [ awwwww ]
mnot: Closed!
mnot: Navigation Error Logging
mnot: They added promises
mnot: I'll check implementation status
mnot: Beacon
Alex: API is ok, but there could be some implementation problems
mnot: NFC API
slightlyoff this API doesn't look half bad!
twirl so many abbreviations
slightlyoff questions for NFC: what about "background" NFC? integration with SW's?
mnot: CSS Font Loading
Domenic: nearly done
mnot: Web MIDID
twirl s/MIDID/MIDI
mnot: Closed
mnot: WebRTC
slightlyoff I think we should perhps try to get the ORTC folks to present?
slightlyoff maybe have them talk to us?
dka: let's organize a call
slightlyoff thanks
slightlyoff I would also like to let both "sides" know that we're paying attention
slightlyoff and would like to see resolution + interop
mnot: Web Components
Domenic: done!
mnot: Push API
Alex: already done, feedback accepted
mnot: Web Audio
Domenic: done
mnot: Compositing and Blending
mnot: Closed
slightlyoff the only thing about Push that's nasty is the verbosity in the API: https://w3c.github.io/push-api/#example
slightlyoff but otherwise I think it's in good shape
twirl verbosity is better than letter-saving
Domenic: next time we should ask authors about preferred form of communication
slightlyoff the call is SUPER static-y now
slightlyoff gonna re-dial
### Topic: Privacyslightlyoff thanks
mnot: I talked with Chrome and HTTP teams, they were frustrated with Privacy mode [not] understood by users
mnot: people don't understand what Privacy Mode guarantees and what does not
mnot: if we standardize definitions of privacy mode it will help
mnot: users and websites will learn what it means
mnot: it's probably a proper moment to act
slightlyoff link?
mnot: I tried to define what browser privacy mode is
mnot: hiding clues from other users of the computer
slightlyoff I'd LOVE for sites to get unique storage in this mode
mnot: hiding from external observers
mnot: hide identity from websites
slightlyoff the measurement APIs are an area we can do better in a privacy mode
slightlyoff also font access
dka: fingerprinting is important too; I can be okay with tracking in regular mode, but I'd like to be not tracked in privacy mode
plinss: but you can, in fact, identify yourself as a person-which-is-untraceable
mnot: browsers should be more agressive in failing situations
mnot: and last one: get user informed
mnot: in privacy mode browser either should either obfuscate traffic or display an alert
Domenic: browsers should compete how many privacy features they implement
Alex: I think in privacy mode access to storages should be restricted
dherman: how could this affect the platform?
slightlyoff specifically I was saying that you might be able to partition storage
mnot: spec editors will be aware of several browser modes
dherman: idea itself seems fruitful, but AFAIK users use Privacy mode for hiding browser history, not to be not tracked
dherman: we should not make decisions based on our view, not real people needs
dherman: it's a product decision, not platform
timbl: that's just a switcher saying "I will be embarassed if anyone knows"
timbl s/knows/knows — it is up to the tech community t try to anctipate the attack vectors, not the user/
dka: there is not enough knowledge [in the public sphere] about when it's a good idea to use privacy modes [i.e. not only when you are trying to "hide" something]
twirl s/there are too less knowledge about/people know very little
JeniT: does this affect server-side?
mnot: in general not; maybe in a form of profiles and cookie politics
dka adjourned
slightlyoff heading off
slightlyoff later all!
dka thx!