Re: Limiting the scope of user permissions

[Frederik Braun]

You can tackle bits of this problem by assigning different subdomains
either per-permission set or per-client.

AFAIU, the settings should be stored independently.

With more and more permissions coming to the web, the numbers of
combinations might grow exponentially though.

On 27.04.2015 12:50, Andy Earnshaw wrote:
> I work for an adserving company, where many third-party creatives are
> served from the same CDN domain.  One of the things we're starting to
> see now is more use of APIs that require permissions, such as
> Geolocation and, since the recent Chrome 42 release, Push Notifications.
> 
> These APIs are great, though I'm particularly a fan of the idea of ads
> trying to "re-engage with users" (the words of one of our clients
> wanting to use these APIs) via push notifications, it's a bit of a scary
> thought.  A user's acceptance or disallowing of permissions presents a
> new problem for us, though.  One third-party creative might be
> uninteresting enough to a specific user such that the user immediately
> chooses to disallow permissions for a specific API, resulting in that
> user never being prompted for those permissions again even if another
> creative they see interests them enough that they would otherwise allow
> them.  Conversely, a user might give their permissions for one creative,
> unwittingly giving the same permissions to all third-party creatives
> from that point on.
> 
> A specific example:
> 
> 1. User visits a website with an ad placement served from our CDN.
> 2. User interacts with the ad, which wants to show him offers from local
> businesses close to him, asking to locate him via the Geolocation API.
> 3. User disallows access to Geolocation API and stops interacting with
> the ad.
> 4. Later, user visits another website with a different ad placement
> served from the same CDN.
> 5. User interacts with the ad, which shows him a map with all the
> advertiser's retail stores as markers on the map.
> 6. User repeatedly clicks the "locator" button on the map with
> frustration, but it has no effect because he already denied permissions
> to the Geolocation API earlier.
> 
> I hope this serves as an appropriate example for the problem.  Similar
> cases could occur with, for example, sites like CodePen or JSFiddle,
> where demonstrations cannot rely on user prompting to actually work. 
> Basically, we need a way of protecting advertisers from each other,
> perhaps by scoping permissions to an origin and path instead of just the
> origin.  I'm not sure how this would work, the best idea I can come up
> with is using a custom HTTP header, for example:
> 
> X-Permissions-Scope: path | host
> 
> I realise that this is outside the scope of the specification and that
> the spec only goes as far as making a recommendation[1] to use the
> origin of the document or worker when making security decisions, but
> this seemed like the best place to start a discussion about it.
> 
> [1]:https://w3c.github.io/permissions/#h-status-of-a-permission

Re: =[xhr]

[Frederik Braun]

Hi,

Thank you for your feedback. Please see the archives for previous
iterations of this discussion, e.g.

(and click "next in thread").


On 29.01.2015 21:04, LOUIFI, Bruno wrote:
> Hi,
> 
> I am really disappointed when I saw in Chrome debugger that the
> XMLHttpRequest.open() is deprecating the synchronous mode. This is was
> the worst news I red since I started working on web applications.
> 
> I don’t know if you release the negative impacts on our professional
> applications. We made a huge effort creating applications on the web and
> also providing JavaScript APIs that behave as Java APIs in order to help
> developers migrating from java to JavaScript technology.
> 
> So please reconsider your decision. Our customers use APIs for their
> professional business. You don’t have right to break their applications.
> 
> Regards,
> 
> Bruno Louifi
> 
> Senior Software Developer
> 

Re: What I am missing

[Frederik Braun]

On 19.11.2014 04:26, Michaela Merz wrote:

> First: We need signed script code. We are doing a lot of stuff with
> script - we could safely do even more, if we would be able to safely
> deliver script that has some kind of a trust model. I am thinking about
> signed JAR files - just like we did with java applets not too long ago.
> Maybe as an extension to the CSP enviroment .. and a nice frame around
> the browser telling the user that the site is providing trusted / signed
> code. Signed code could allow more openness, like true full screen, or
> simpler ajax downloads. 

Well, you can't sign or verify with Subresource Integrity (SRI), but SRI
allows you to make sure that it has not been tampered with on the
hosting side: 

Re: Service worker popup (rich notification)

[Frederik Braun]

On 02.10.2014 21:34, Jonas Sicking wrote:
> On Thu, Oct 2, 2014 at 11:31 AM, Anne van Kesteren  wrote:
>> On Thu, Oct 2, 2014 at 8:27 PM, John Mellor  wrote:
>>> This seems to either require a somewhat stronger trust signal from the user,
>>> or a very easy mechanism for revoking the permission if the website does
>>> spam you; and probably in either case showing the url bar should be
>>> compulsory to prevent phishing. But this isn't something we've thought about
>>> deeply yet.
>>
>> Indeed. The Notifications API is nice, but it's not suitable for this.
>> You need a browsing context of sorts so you can show images, video,
>> buttons, etc.
> 
> Indeed. I wouldn't call these notifications at all. What's needed here
> is to launch full browser windows so that we can display full-screen
> or full-window UIs to the user. To make matters even more complicated,
> generally speaking you want to be able to do this on a mobile device,
> even if it's "locked".
> 
> I.e. an alarm clock app wouldn't be terribly useful if it only worked
> when the device was unlocked. And a skype app wouldn't be terribly
> useful if you could only receive calls when the device was unlocked.
> 
> Fortunately, while this goes outside the browser window, it doesn't
> "break the same-origin boundary". So it should be quite possible to
> solve this the same way we're planning on solving other such APIs,
> like storage, indexedDB and notifications. I.e. make the API async and
> then leave it up to UAs to implement policies.
> 
> / Jonas
> 

We have something similar in FirefoxOS per-app window:
window.open(url, "", "dialog");

We also have the so called "attention" screen, that requires a special
permission and is on top of everything (e.g. for alarm clocks and
incoming calls):
window.open(url, "", "attention");


Which of these use-cases are we discussing here?

Re: HTML imports: new XSS hole?

[Frederik Braun]

On 04.06.2014 11:00, Anne van Kesteren wrote:
> On Tue, Jun 3, 2014 at 7:20 PM, Oda, Terri  wrote:
>> Perhaps it would make sense to also require explicit allowing of imports via
>> CSP?  Scripts are allowed when no CSP is provided for historical
>> compatibility so you'd need to make sure that imports fell under a separate
>> directive, but there's no need for backwards compatibility so it probably
>> makes sense to choose a more conservative default behaviour for HTML
>> Imports.
> 
> Using  seems like a solution that would be better in
> that case, as it does not provide opt-in through HTTP. Whenever we
> require HTTP for a feature, we get a ton of complaints. And