On Mon, 19 Mar 2012 11:53:48 +1100
ianG wrote:
> On 19/03/12 08:19 AM, Kevin Chadwick wrote:
> > On Sun, 18 Mar 2012 12:30:35 +1100
>
>
> On the MITM - FUD or validated threat?
http://www.h-online.com/security/news/item/28C3-New-attacks-on-GSM-mobiles-and-security-measures-shown-1401668.html
N
On Sat, Mar 17, 2012 at 6:18 PM, Asa Dotzler wrote:
> On 3/17/2012 3:17 AM, Andreas Gal wrote:
>
>>
>> We have trained users over a long period of time to think of
>> sites/origins and not the actual code when making security decisions. The
>> whole code signing discussion is a total distraction
On Mon, 19 Mar 2012 12:31:05 +
Ben Francis wrote:
> A user granting permissions
> expresses trust in the people hosting a web site/app, not the code itself.
No, it can be and is both or either. Take android. Some apps I trust
the author and hope he's responsible with his signing infrastructur
On 3/17/2012 6:17 AM, Andreas Gal wrote:
We have trained users over a long period of time to think of sites/origins and
not the actual code when making security decisions. The whole code signing
discussion is a total distraction here. Web apps should use the same basic
security model the web i
On Mon, Mar 19, 2012 at 12:31 PM, Ben Francis wrote:
> Having said that, one thing I'm unsure about is the restriction of "one web
> app per origin" and "one origin per web app". Do you think this this
> flexible enough in practice?
flexibility is not the only concern. a manifest with wildcard
I think the same system works just fine, with a twist. For highly privileged
APIs only trusted stores can grant access and those stores can require to host
your code from a domain they control. This requires much less reinventing the
web than the signature idea. The Mozilla store for example can
On Mon, Mar 19, 2012 at 3:19 PM, Andreas Gal wrote:
> I think the same system works just fine, with a twist. For highly privileged
> APIs only trusted stores can grant access
andreas - it's fine to propose such, but first you have to actually
think it through: how is that enforced?
> and those
Does this mean that the store has to host all the backend data and services?
Since the standard model is that web sites are generally restricted to
connecting to their origination domain, the would mean that an app would be
restricted to connecting to app5472.mozilla.org. Even if app5472.mozil
We don't have to host major sites. All that has to be in place is some form of
trust. Trust can come from hosting the code on the store (easy, scales), or a
contract (scales less, but more flexible). In case of facebook it would clearly
be the latter.
Andreas
On Mar 19, 2012, at 11:22 AM, Jim
On Mon, Mar 19, 2012 at 10:19 AM, Andreas Gal wrote:
> I think the same system works just fine, with a twist. For highly
> privileged APIs only trusted stores can grant access and those stores can
> require to host your code from a domain they control. This requires much
> less reinventing the we
a word to those people who are also "outsiders". the B2G team have
seen fit to enact censorship of the dev-b2g mailing list on the 17th
march 2012, preventing and prohibiting messages from reaching the
dev-b2g recipients.
i do not ask you to judge such decision-making but i simply make you
aware
On 16/03/12 14:53, Kevin Chadwick wrote:
If you don't need background data. You can disable that and get no
automatic update checks.
Turning off updates, including security updates, doesn't sound to me
like an awesome solution to the problem of being nagged about them...
"Hey, if you cancel
That is may (or may not) fine for desktop web apps. But for mobile devices
(B2G), web access won't always be available. Even on a desktop, I can enable a
rule in a tool like Little Snitch and keep an app from connecting to a specific
server/port. There are lots of apps that don't need server
On Mar 19, 2012, at 1:36 PM, Jim Straus wrote:
> What I would like to see is a threat tree, how we may mitigate the various
> threats, and an assessment of how far we feel we need to go. That's why I'm
> adding in dev-security to this thread. I want us to have a robust developer
> community.
On Mon, 19 Mar 2012 19:57:20 +
Gervase Markham wrote:
> Turning off updates, including security updates, doesn't sound to me
> like an awesome solution to the problem of being nagged about them...
>
> "Hey, if you cancel your fire insurance, you don't get nagging letters
> every year tellin
On Mon, 19 Mar 2012 19:37:15 +
lkcl luke wrote:
> i do not ask you to judge such decision-making but i simply make you
> aware of it, such that if you find such actions questionable you can
> take it into account, such as by replying to messages which have been
> sent to you (directly or as pa
- Original Message -
> From: "Anant Narayanan"
> To: "Jim Straus"
>
> How do native apps deal with this? My limited understanding is that
> they implement some DRM scheme based on information they get about
> the uniqueness of the device they are running on (example: MAC
> address). Steam
On Mar 19, 2012, at 2:27 PM, David Chan wrote:
> Steam generates a custom binary for each user. See CEG Overview on
> https://partner.steamgames.com/documentation/api
>
> I'm guessing that some sort of receipt / decryption key is stored on
> the local machine when you enable offline mode. They als
18 matches
Mail list logo
