Re: [mobile-web] Detecting non-mobile browsers using regex at web-server. Reliable?

Sorry for the cross posting...but I think this is an important
discussion that crosses over the DAPI group too.  I think the w3c would
be interested in debate around the OneWeb definition too...see full
thread at the bottom.


On Tue, 2011-03-29 at 11:27 -0600, Peter Cranstone wrote:
> As for the database comment. Let’s think about it another way which
> everyone is familiar with - “an app for that”. Here’s the “thought
> experiment”.

Yeah...I think that's a better positioning based on where everyone's
head is at...but obviously would need to be set deeper into the browser
or phone OS to be truly useful.


> All I’ve done above is to describe something similar to the DAPI but
> with even more context. 

Yep...and I agree it has to happen in one way or another.  I think the
graded control that OAuth can provide is exactly this type of
model...and that's already achieved wide adoption.

I think combining it with a server side (I refuse to use the word cloud)
data stores that you can also control makes it really useful.  Then you
can turn on and off the permission you have given to third parties to
use your data.  And best of all you'd get a full audit trail...and the
app could alert you when a third party wanted to access some particular
personal information and you could just click "allow or deny".


> There’s no question that it’s going to be done - the question becomes
> “what’s the best approach”. Everybody wants a piece of the consumer.
> The more context you have about them, the more value you can generate.

Absolutely agree.  But I think it's better if this is done at a lower
level than just an app (I know you were just using that as a
metaphor) ...however it is a real point of difference that browser
vendors could use to show users they're better/different by integrating
with this type of model.


>  You would not believe what Google’s Android browser is already
> sending back to HQ.

I know...and it's not a good thing.  I'm surprised it hasn't gotten as
much attention as the streetview mac address sniffing did.



roBman

> On Mar 29, 2011, at 9:07 AM, Rob Manson wrote:
> 
> >   
> > I have to say that I'm confused how you could dismiss the OneWeb
> > concept
> > altogether Luca. I think you're right about that w3c doc being very
> > broadly worded to the point of almost saying nothing...but the
> > underlying concept is real and is really common...if not THE most
> > common
> > URL based experience today.
> > 
> > People share links via twitter or facebook. You post ONE link and
> > almost instantly people from all over the world with all sorts of
> > devices start accessing that URL. This context makes device specific
> > URLs meaningless...plus it's stupid to ask users to select what the
> > machines should be able to sort out themselves
> > (m.? .mobi? /m? /iphone?
> > blergh!). This is just the modern content negotiation environment
> > that
> > HTTP has created and is perfectly suited for.
> > 
> > The modern permalink just has to support this if it wants to be a
> > true
> > permalink and have real utility.
> > 
> > I also do agree with Peter about extending and using HTTP to let
> > clients
> > make more informed/sophisticated requests in collaboration with
> > consenting servers. However, Peter I must say the way you describe
> > it
> > as "putting the database on the client" really threw me for a minute
> > 8)
> > Sorry but I don't think I'll be using that turn of phrase to try to
> > convince anyone on this point...but I think the underlying point
> > that
> > you're making is really true.
> > 
> > The device market will continue to fragment and more sophisticated
> > capability/content negotiation will be required. And the DAPI layer
> > will expose more significant information, private content and
> > invasive
> > sensor data. The users will need to be given more control over which
> > applications and servers are able to access and manipulate this.
> > 
> > And users just expect to seamlessly move from one channel/device to
> > another with the data/content fluidly following them. This is a good
> > thing in my world...
> > 
> > roBman
> > 
> > On Tue, 2011-03-29 at 08:04 -0600, Peter Cranstone wrote:
> > > Totally agree with the definition, especially this point:
> > > 
> > > 
> > > It is likely that application designers and service providers
> > > will wish to 
> > > provide the best possible experience in the context in which
> > > their service has 
> > > the most appeal. However, while services may be most
> > > appropriately experienced 
> > > in one context or another, it is considered best practice to
> > > provide as 
> > > reasonable experience as is possible given device limitations
> > > and not to exclude 
> > > access from any particular class of device, except where this
> > > is necessary 
> > > because of device limitations.
> > > 
> > > 
> > > Let me summarize - context is critical when it comes to device
> > > detection. Supply the relevant context and you have the ability to
> > > adapt to the device, the location and the user.
> > > 
> > > 
> > > In other words, everything is achievable if you stack up
> > > enough ifs. Then you 
> > > have reality... and devices which won't tell the server who
> > > they are because 
> > > they don't want to…
> > > 
> > > 
> > > As they would say in America - “swing and a miss”. 
> > > 
> > > 
> > > Seriously you need to sit down and think about how you would solve
> > the
> > > problem. Saying the “devices won’t tell the server who they are
> > > because they don’t want to” is ridiculous. The device is not a
> > > sentient being. It does what it’s told to do. 
> > > 
> > > 
> > > What you’re now bringing up is the issue of privacy - in as much
> > how
> > > do you control “what context is being shared from the device”. So
> > > imaging this (not hard really) there’s a database on the device
> > (WURFL
> > > uses a database so we’re on the same page here).
> > > 
> > > 
> > > In that database is “meta data about the device, the current
> > location
> > > and some other personal information”. That database is controlled
> > by
> > > the user. The user selects to send that data to a Web
> > site /content
> > > provider they trust. They click a check box and next time they go
> > to
> > > www.itrust.com all of their data shows up in the request headers.
> > > 
> > > 
> > > Now tell me what’s wrong with that? All that’s happened is the
> > WURFL
> > > database is flipped to the device and includes more “contextual
> > > data”. 
> > > 
> > > 
> > > And then you wrote this:
> > > 
> > > 
> > > There is little point in fixing the technology, if the
> > > industry has still not 
> > > agreed on the economic models that the technology is supposed
> > > to enable.
> > > 
> > > 
> > > Again “swing and a miss”.
> > > 
> > > 
> > > Let me use the WURFL analogy - WURFL was invented (by you) to
> > solve a
> > > problem. The problem is explicit - what are the device
> > capabilities of
> > > the connecting device. So tell me what the economic model is
> > behind
> > > using WURFL? Pretty obvious if you think about it - if you know
> > the
> > > capabilities of the connecting device you’ll “tailor” your content
> > to
> > > deliver the most relevance and the most value. The core problem
> > > remains - real time device detection. The economic model is also
> > clear
> > > - deliver value to the connecting device by using device detection
> > to
> > > ensure as much relevance as possible.
> > > 
> > > 
> > > Everybody out there wants to solve the problem on the server side.
> > No
> > > one ever thought of solving it on the client side. Why? A number
> > of
> > > reasons…
> > > 
> > > 
> > > * Really hard
> > > * Has to work with every firewall, filter, router etc
> > > * Has to work with 250m Web servers out there
> > > * Has to follow ALL Web standards
> > > * Has to seamlessly integrate with everything 
> > > * Has to follow the law of “least astonishment” 
> > > * Has to work on multiple OS
> > > 
> > > 
> > > In short - it’s easier to do it on the server.
> > > 
> > > 
> > > WURFL is/was a great idea - if you want to solve the problem from
> > the
> > > server. All I’m saying is “what if that database existed on the
> > > client”.
> > > 
> > > 
> > > Think about it.
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Peter
> > > __________________________________
> > > Peter J. Cranstone
> > > M: 720.663.1752
> > > 5o9, Inc.
> > > CEO
> > > 
> > > 
> > > 
> > > 
> > > Web Tools for Mobile
> > > 
> > > On Mar 29, 2011, at 7:45 AM, Luca Passani wrote:
> > > 
> > > > On 29/03/2011 15.04, Peter Cranstone wrote:
> > > > > FWIW - the One Web is not bullshit. No more than designing a
> > Web
> > > > > site for a 
> > > > > Mobile device is bullshit.
> > > > 
> > > > yes it is, but since you seem eager to re-open the discussion, I
> > > > will articulate 
> > > > better.
> > > > 
> > > > here is the definition of One Web (and if you mean something
> > > > different, please 
> > > > explain):
> > > > 
> > > > http://www.w3.org/TR/mobile-bp/#OneWeb
> > > > 
> > > > ".../One Web/means making, as far as is reasonable, the same
> > > > information and 
> > > > services available to users irrespective of the device they are
> > > > using. However, 
> > > > it does not mean that exactly the same information is available
> > in
> > > > exactly the 
> > > > samerepresentation 
> > > > <http://www.w3.org/TR/di-gloss/#def-http-representation>across
> > all
> > > > devices. The 
> > > > context of mobile use, device capability variations, bandwidth
> > > > issues and mobile 
> > > > network capabilities all affect the representation. Furthermore,
> > > > some services 
> > > > and information are more suitable for and targeted at particular
> > > > user contexts 
> > > > (see5.1.1 Thematic Consistency of Resource Identified by a URI 
> > > > <http://www.w3.org/TR/mobile-bp/#tc>).
> > > > 
> > > > Some services have a primarily mobile appeal (location based
> > > > services, for 
> > > > example). Some have a primarily mobile appeal but have a
> > > > complementary desktop 
> > > > aspect (for instance for complex configuration tasks). Still
> > others
> > > > have a 
> > > > primarily desktop appeal but a complementary mobile aspect
> > (possibly
> > > > for 
> > > > alerting). Finally there will remain some Web applications that
> > have
> > > > a primarily 
> > > > desktop appeal (lengthy reference material, rich images, for
> > > > example).
> > > > 
> > > > It is likely that application designers and service providers
> > will
> > > > wish to 
> > > > provide the best possible experience in the context in which
> > their
> > > > service has 
> > > > the most appeal. However, while services may be most
> > appropriately
> > > > experienced 
> > > > in one context or another, it is considered best practice to
> > provide
> > > > as 
> > > > reasonable experience as is possible given device limitations
> > and
> > > > not to exclude 
> > > > access from any particular class of device, except where this is
> > > > necessary 
> > > > because of device limitations.
> > > > 
> > > > From the perspective of this document this means that services
> > > > should be 
> > > > available as some variant of HTML over HTTP (see3.7 Default
> > Delivery
> > > > Context 
> > > > <http://www.w3.org/TR/mobile-bp/#ddc>)."
> > > > 
> > > > Now, this is obviously a rather ambiguous definition. It does
> > not
> > > > seem to 
> > > > mandate anything specific in practice. On one end, you have the
> > > > interpretation 
> > > > that, if possible, one should make the same information
> > available to
> > > > both mobile 
> > > > and desktop users. Of course, if this is not possible or does
> > not
> > > > make business 
> > > > sense, "designers and service providers" are free to do what
> > they
> > > > want => One 
> > > > Web is pointless
> > > > 
> > > > At the other extreme, you have that One Web should be
> > interpreted
> > > > more 
> > > > strictly, and "designers and service providers" have an
> > obligation
> > > > of some kind 
> > > > to make the same content available to both mobile users and web
> > > > users => One Web 
> > > > is wrong.
> > > > I can think of countless scenarios where content owners may not
> > want
> > > > to publish 
> > > > the same content on the web and mobile channels.
> > > > 
> > > > So, One Web is a vaguely defined concept hanging somewhere
> > between
> > > > pointlessness 
> > > > and wrongness.
> > > > At best, it's a positive advice ("don't be evil with mobile
> > users").
> > > > At worst, 
> > > > it's an artificial obstacle for those who have a specific
> > business
> > > > model to 
> > > > support. I am not sure what anyone would expect developers to do
> > > > with it.
> > > > 
> > > > 
> > > > > 
> > > > > You’ve missed the core problem - real time device detection.
> > IF
> > > > > the HTTP 
> > > > > protocol supported it correctly you wouldn’t need WURFL
> > because it
> > > > > (the 
> > > > > connecting device) would tell the server in real time what
> > it’s
> > > > > capable of doing.
> > > > 
> > > > ...and the classic counter objection to this kind of arguments
> > in
> > > > italian is: 
> > > > "if granma had wheels, she would be a wheelbarrow".
> > > > 
> > > > In other words, everything is achievable if you stack up enough
> > ifs.
> > > > Then you 
> > > > have reality... and devices which won't tell the server who they
> > are
> > > > because 
> > > > they don't want to...
> > > > 
> > > > There is little point in fixing the technology, if the industry
> > has
> > > > still not 
> > > > agreed on the economic models that the technology is supposed to
> > > > enable.
> > > > 
> > > > Luca
> > > > 
> > > > 
> > > > 
> > > > ------------------------------------
> > > > 
> > > > Yahoo! Groups Links
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
>

Received on Wednesday, 30 March 2011 01:38:21 UTC