Re: Subresource integrity and mixed-content warnings

Even if bandwidth weren' an issue, I wouldn't want to proxy them anyway. I
like podcasts for the same reason I like the web, anyone can set up their
own little corner of the internet, without a middleman. I don't want to
become a middleman in podcasting, Collecting analytics on podcasts is also
hard enough as it is already. I don't want to limit the data podcasters get
about their listeners even more.

On Mon, May 23, 2016 at 9:58 PM Crispin Cowan <crispin@microsoft.com> wrote:

> Its not lying; the content stream really is coming from
> HTTPS://yoursever.com/ complete with all 3 guarantees. The hidden fact
> that yourserver.com is fetching its bitstream from a Ouija board is a
> separate matter J This is similar to the discussion we had at the F2F a
> week ago; HTTPS guarantees that yourserver.com said it, but does not and
> cannot guarantee where yourserver.com got it from.
>
>
>
> But yes it likely is an issue WRT the originator’s TOS, get your own
> lawyer etc., and definitely would be a bandwidth issue.
>
>
>
> *From:* Chris Palmer [mailto:palmer@google.com]
> *Sent:* Monday, May 23, 2016 12:12 PM
> *To:* Frederik Creemers <frederikcreemers@gmail.com>
> *Cc:* public-webappsec@w3.org
> *Subject:* Re: Subresource integrity and mixed-content warnings
>
>
>
> On Mon, May 23, 2016 at 12:04 PM, Frederik Creemers <
> frederikcreemers@gmail.com> wrote:
>
>
>
> Thank you for the reply, it makes total sense. It looks to me like the
> biggest issue here is transparency to the user. Security and privacy are
> complicated, even for tech savvy people, and you can't expect most people
> to take the time to overthink what security guarantees a particular web
> application they're using does and does not offer, so I understand browsers
> want to give users a very clear "this website is secure" or "this website
> is not secure" signal. Your response has also made me realize that there's
> no workaround for this that I can implement, as there's nothing that I can
> set up to magically make the connection between the user's browser and the
> podcaster's server secure (authenticated and encrypted).
>
>
>
> Well, technically, it would be possible to lie. You could have your server
> proxy the original podcast servers, and then the browsers would think that
> the podcasts came from https://yourserver.com.
>
>
>
> But, that would be lying :) and it would also incur heavy bandwidth costs
> on you. Also, I am not a lawyer, but it might be that not all podcast
> publishers would approve of such a plan.
>
>
>
> I guess the only thing I can do is hope that media servers start accepting
> secure connections as quickly as possible.
>
>
>
> If it makes you feel any better, you're not alone. :)
>