Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Another loss for the Internet

Jonathan Wilkes jancsika at yahoo.com
Wed Feb 19 15:21:56 PST 2014


On 02/19/2014 03:56 PM, Mitar wrote:
> Hi!
>
> I would like to point to this change in the future W3C spec:
>
> https://github.com/w3c/webappsec/commit/cbfaa8edfadebf21a9c7428242c12e45934d8c55
>
> This change effectively allows a website to prevent bookmarklets from
> working. In essence, content providers can prevent users to execute
> their own bookmarklets and change how website behaves. It requires
> users to use extensions and not simple scripts.
>
> I think this is a step back and makes web something where user is not
> in control anymore.

I think Glenn Adams hits on something in a comment from the bug report 
you linked to below:

"For example, say I'm a commercial television service provider using the 
Open Web Platform to deliver television content to the user. At some 
point, I may need to send an Emergency Alert Message (EAM) to the user 
to warn her of a tornado heading towards her house. A function which the 
Government imposes on me to satisfy, and, even potentially to suffer 
liability consequences if I fail to do my best effort to deliver and 
display (or provide audio override).

"Now say that the user has installed a third party add-on that either 
accidentally or intentionally (through design or through compromise) 
blocks or otherwise prevents my "TV Web Application" from delivering 
that EAM to the user, and, consequently their house is destroyed, 
potentially with loss of life.

"Perhaps I am now sued for liability for such losses due to the fact 
that I failed to deliver or otherwise alert the user. Did I do 
everything I could under the circumstances to attempt delivery? Barring 
the behavior of the add-on, I can probably effectively argue that yes I 
did. However, if I could have told the UA to disable add-ons while the 
user is watching TV via this web application, then I might have 
prevented the add-on from blocking the EAM. A reasonable jury might find 
that I am liable for losses."

You may think that is a highly anachronistic edge-case with which to 
explain one's argument, but read it closely.  He's saying that the 
people in charge of the web-- content providers-- have a reasonable 
desire to limit their own liability.  That's 100% true.

The only question left is-- who are the content providers?  If you 
answer like Glenn then it's companies like the member organizations of 
the W3C, who seem quite happy to chronically compare content that has $0 
marginal cost to ancient technology, as Glenn does here with TV 
emergency broadcasts.  Then the only questions left are technical ones.  
And I can guarantee that if you try to fight intelligent technocrats 
like him you will lose.  (Notice the bug was closed by just removing the 
entire line from the spec, rather than continue arguing with his member 
organization through him.)

If you answer that you and anyone with a general purpose computer hooked 
up to the internet are the real content providers, then you better 
figure out how to limit your liability.  The only answer I see is to 
support secure, anonymous overlays that can deliver the kind of content 
we are afraid will become limited by moves like this or EME.  The only 
project I've seen that could actually deliver that is Gnunet, but it 
looks like it's still under heavy development.

Of course even a functioning overlay isn't perfect.  Most content 
providers I know would rather get attribution than remain anonymous.  
Still, it's leverage, and without an overlay that let's us easily 
broadcast all kinds of content (i.e., not Tor), we don't have very much.

-Jonathan

>
> Read more here:
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23357
> http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0165.html
>
>
> Mitar
>




More information about the liberationtech mailing list